This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Global analysis of RTL


Hi,

On 26 October 2017 at 14:13, R0b0t1 <r030t1@gmail.com> wrote:
> On Thu, Oct 19, 2017 at 8:46 AM, Geoff Wozniak <gcc@geoff.wozniak.ca> wrote:
>> R0b0t1 <r030t1@gmail.com> writes:
>>>
>>> When I first looked at the GCC codebase, it seemed to me that most
>>> operations should be done on the GIMPLE representation as it contains the
>>> most information. Is there any reason you gravitated towards RTL?
>>
>>
>> Naiveté, really.
>>
>> My team and I didn’t know much about the code base when we started looking
>> at the problem, although we knew a little about the intermediate formats.
>> GIMPLE makes the analysis more complicated, although not impossible, and it
>> can make the cost model difficult to pin down. Raw assembly/machine code is
>> ideal, but then we have to deal with different platforms and would likely
>> have to do all the work in the linker. RTL is sufficiently low-level enough
>> (as far as we know) to start counting instructions, and platform independent
>> enough that we don’t have to parse machine code.
>>
>> Essentially, working with RTL makes the implementation a little easier but
>> we didn’t know that the pass infrastructure wasn’t in our favour.
>>
>> It’s likely we’ll turn our attention to GIMPLE and assembler/machine code,
>> unless we can come up with something (or anyone has a suggestion).
>>
>
> Admittedly I do not know much about compiler design, but your response
> has put some of what I read about analysis of RTL into context. It it
> is hard to be sure, but I think analysis of RTL has fallen out of
> favor and has been replaced with the analysis of intermediate
> languages. For example, compare clang and llvm's operation.

It is not really being replaced (at least I am not aware of it). It is
true that more and more of the high level optimisations are moved to
gimple. When we move high level intermediate format to lower level
intermediate format, we tend to lose some information and gets more
closer to machine representation. An obvious example is, in RTL sign
is not represented. Even in RTL, after reload, we will have one to one
mapping fro RTL to actual machine instruction (i.e. more closer to
asm). In short, gcc goes from generic to gimple to RTL as stamens are
lowered from high level languages to asm.

Thanks,
Kugan

>
> The missing link is that you seem to be right about cost calculation.
> Cost calculation is difficult for high level operations. Would online
> analysis of the produced machine code be sufficient? That seems to be
> a popular solution from what I have read.
>
> Thanks for the response, and best of luck to you.
>
> Cheers,
>      R0b0t1.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]