RTL frontend, insn recognition, and pointer equality

David Malcolm dmalcolm@redhat.com
Thu Oct 20 14:51:00 GMT 2016


On Thu, 2016-10-20 at 13:02 +0200, Bernd Schmidt wrote:
> 
> 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.

Thanks; I'll look into this.

> > I'd hope you already have pointer equality for all instances of
> > each
> > pseudo register.

The loader already does this; I'll add an explicit selftest for it.
 
> 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.

match_dup is within the part of rtl.def that's guarded by
#ifdef GENERATOR_FILE, so as-is we can't use match_dup on the host
(unless we expose it there, I suppose).  But we may be able to special
-case it in the loader, and do it directly (or give it its own name,
maybe "reuse_rtx"?)

As for syntax, I think I prefer to have the ID to appear within the
paren, since we have enough weird syntax to cope with within the
operands, so it might look like:

   ({0} scratch:DI)
or:
   (0|scratch:DI)

with the insn as a whole looking like:

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




More information about the Gcc-patches mailing list