RTL frontend, insn recognition, and pointer equality

Bernd Schmidt bschmidt@redhat.com
Thu Oct 20 11:02:00 GMT 2016



On 10/20/2016 11:22 AM, Bernd Schmidt wrote:
> On 10/20/2016 01:49 AM, David Malcolm wrote:
>>
>> (b) for all codes for which rtx_equal_p requires pointer equality, add
>> some kind of extra ID to the dump, allowing the loader to reconstruct
>> the graph.  This could be the pointer itself:
>>
>>   (scratch:DI [0x7ffff19ee150])
>>   (scratch:DI [ptr:0x7ffff19ee150])
>>
>> or somesuch, but it would perhaps be better to use some kind of more
>> human-friendly ID e.g.
>>
>>   (scratch:DI [ptr-idx: 42])
>>
>> or similar, rather than subject ourselves to raw hex values.  Probably
>> need an extra flag to print-rtl.c, to avoid making the dumps more
>> verbose for everyone who doesn't want this (if so, does "compact" mode
>> need renaming...)
>>
>> Or just do this for SCRATCH, maybe?
>
> Recognizing by SCRATCH wouldn't catch everything, I believe. You should
> be able to check n_dups and dup_loc in recog_data to identify cases
> where you need to ensure something is restored with pointer equality.
>
> I'd hope you already have pointer equality for all instances of each
> pseudo register.

As for the output format, I think you're on the right track assigning 
IDs, but maybe the following would be easier to parse for machines and 
humans:

       (cinsn (set (mem/v:BLK {0}(scratch:DI) [0  A8])
                     (unspec:BLK [
                             (mem/v:BLK (match_dup 0) [0  A8])
                         ] UNSPEC_MEMORY_BLOCKAGE)) "test.c":2
                  (nil))

where the {0} could be recognized as a prefix saying "store the address 
of the next rtx into slot 0, with a finalization pass replacing 
match_dups with the corresponding address.

Could also maybe do something like (0|scratch:DI), that ought to also be 
unambiguous.


Bernd



More information about the Gcc-patches mailing list