From: Leslie Zhai <lesliezhai@llvm.org.cn>
To: dag@cray.com, vmakarov@redhat.com, LewisR9@cf.ac.uk, stoklund@2pi.dk
Cc: GCC Development <gcc@gcc.gnu.org>,
LLVM Developers Mailing List <llvm-dev@lists.llvm.org>
Subject: Re: Register Allocation Graph Coloring algorithm and Others
Date: Mon, 18 Dec 2017 17:52:00 -0000 [thread overview]
Message-ID: <a1e8dd77-b30d-4b69-6b45-bf68fad8556f@llvm.org.cn> (raw)
In-Reply-To: <nngbmiwc7je.fsf@lnx-dag.us.cray.com>
Hi David,
Thanks for your teaching!
I am a newbie in compiler area, I only learned Compiler Principle in
2002 https://www.leetcode.cn/2017/12/ilove-compiler-principle.html
But I like to practice and learn :)
https://github.com/xiangzhai/llvm/blob/avr/lib/CodeGen/RegAllocGraphColoring.cpp#L327
because theory is not always correct, or misunderstood by people, so I
want to compare solutionByHEA, IRA, Greedy, PBQP and other algorithms.
Thanks for your lessons to correct my mistakes, such as memory=bad
register=good, and I need to find the answer *when* memory is worse than
a register, I am maintaining AVR target, there are 32 general registers,
32K flash, 2K sram
http://www.atmel.com/Images/Atmel-42735-8-bit-AVR-Microcontroller-ATmega328-328P_Datasheet.pdf
so perhaps to MCU, memory might be expensive than register? but what
about AMDGPU or VLIW processors? I don't have experienced on them,
please teach me.
I am reading LLVM's code SpillXXX, LiveRangeXXX, RegisterCoalescer, etc.
to get the whole view of CodeGen.
I am reading Dr. Rhydian Lewis's book: A Guide to Graph Colouring:
Algorithms and Applications
http://www.springer.com/us/book/9783319257280Â Â and other papers, even
if HEA is not the best solution, I still want to practice and see the
benchmark, I am not computing professionals, I am only 34 olds, perhaps
I have enough time to waste :)
å¨ 2017å¹´12æ19æ¥ 00:41, dag@cray.com åé:
> Leslie Zhai <lesliezhai@llvm.org.cn> writes:
>
>> * Memory (20 - 100 cycles) is expensive than Register (1 cycle), but
>> it has to spill code when PhysReg is unavailable
> As Vladimir said, the cache makes this kind of analysis much more
> tricky. It's not necessarily the case that memory=bad and
> register=good. Since there are tradeoffs involved, one needs to
> evaluate different strategies to determine *when* memory is worse than a
> register. It may very well be the case that leaving something in memory
> frees up a register for something much more important to use it. All of
> the register allocation algorithms try to determine this kind of thing
> through various heuristics. Which heuristic is most effective is highly
> target-dependent.
>
> In my experience, changing heuristics can swing performance 20% or more
> in some cases. Today's processors and memory systems are so complex
> that 2nd- and even 3rd-order effects become important.
>
> It is very, very wrong on today's machines to use # of spills as a
> metric to determine the "goodness" of an allocation. Determining *what*
> to spill is much more important than the raw number of spills. Many
> times I have a seen codes generated with more spills perform much better
> than the code generated with fewer spills. Almost all of the papers
> around the time of Chaiten-Briggs used # of spills as the metric. That
> may have been appropriate at that time but take those results with giant
> grains of salt today. Of course they are still very good papers for
> understanding algorithms and heuristics.
>
> The best way I know to determine what's best for your target is to run a
> whole bunch of *real* codes on them, trying different allocation
> algorithms and heuristics. It is a lot of work, still worthy of a
> Ph.D. even today. Register allocation is not a "solved" problem and
> probably never will be as architectures continue to change and become
> ever more diverse.
>
>> * Folding spill code into instructions, handling register coallescing,
>> splitting live ranges, doing rematerialization, doing shrink wrapping
>> are harder than RegAlloc
> Again, as Vladimir said, they are all part of register allocation.
> Sometimes they are implemented as separate passes but logically they all
> contribute work to the task of assigning registers as efficiently as
> possible. And all of them use heuristics. Choosing when and when not
> to, for example, coalesce can be important. Splitting live ranges is
> logically the opposite of coalescing. Theoretically one can "undo" a
> bad coalescing decision by re-splitting the live range but it's usually
> not that simple as other decisions in the interim can make that tricky
> if not impossible. It is a delicate balancing act.
>
>> * The papers by Briggs and Chaiten contradict[2] themselves when
>> examine the text of the paper vs. the pseudocode provided?
> As others have said, I don't recall any inconsistencies but that doesn't
> mean there aren't bugs and/or incomplete descriptions open to
> interpretation. One of my biggest issues with our computer academic
> culture is that we do not value repeatability. It is virtually
> impossible to take a paper, implement the algorithm as described (or as
> best as possible given ambiguity) and obtain the same results. Heck,
> half my Ph.D. dissertation was dissecting a published paper, examining
> the sensitivity of the described algorithm to various parts of the
> described heuristic that were ambiguous. By interpreting the heuristic
> description in different ways I observed very different results. I read
> papers for the algorithms, heuristics and ideas in them. I pay no
> attention to results because in the real world we have to implement the
> ideas and test them ourselves to see if they will help us.
>
> Peter is right to point you to Preston. He is very accessible, friendly
> and helpful. I had the good fortune to work with him for a few years
> and he taught me a lot. He has much real-world experience on codes
> actually used in production. That experience is gold.
>
> Good luck to you! You're entering a world that some computing
> professionals think is a waste of time because "we already know how to
> do that." Those of us in the trenches know better. :)
>
> -David
--
Regards,
Leslie Zhai - https://reviews.llvm.org/p/xiangzhai/
next prev parent reply other threads:[~2017-12-18 17:52 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-15 3:19 Leslie Zhai
2017-12-15 4:40 ` Vladimir Makarov
2017-12-15 4:59 ` Leslie Zhai
2017-12-15 14:48 ` Peter Bergner
2017-12-18 16:42 ` dag
2017-12-18 17:52 ` Leslie Zhai [this message]
2017-12-18 22:35 ` dag
[not found] ` <9CBFCADA170A6854@apple.com>
[not found] ` <6708A731-203E-4096-8137-85D4104DA035@apple.com>
2017-12-19 3:03 ` [llvm-dev] " Leslie Zhai
2017-12-20 17:25 ` Jakob Stoklund Olesen
2017-12-21 0:44 ` Leslie Zhai
[not found] ` <5a3b03ec.01da9f0a.1934a.4b3bSMTPIN_ADDED_BROKEN@mx.google.com>
2017-12-21 11:09 ` [llvm-dev] " Bruce Hoult
2017-12-21 16:26 ` Leslie Zhai
[not found] <615F0DCE4D5873A9@mac.com>
2017-12-19 0:07 ` Michael Clark
2017-12-19 2:10 ` Leslie Zhai
2017-12-19 4:16 ` Vladimir Makarov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a1e8dd77-b30d-4b69-6b45-bf68fad8556f@llvm.org.cn \
--to=lesliezhai@llvm.org.cn \
--cc=LewisR9@cf.ac.uk \
--cc=dag@cray.com \
--cc=gcc@gcc.gnu.org \
--cc=llvm-dev@lists.llvm.org \
--cc=stoklund@2pi.dk \
--cc=vmakarov@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).