Re: RTL frontend, insn recognition, and pointer equality

2016-10-20 Thread Bernd Schmidt
On 10/20/2016 04:51 PM, David Malcolm wrote: (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_MEMO

Re: RTL frontend, insn recognition, and pointer equality

2016-10-20 Thread David Malcolm
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

Re: RTL frontend, insn recognition, and pointer equality

2016-10-20 Thread Bernd Schmidt
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 [

Re: RTL frontend, insn recognition, and pointer equality

2016-10-20 Thread Bernd Schmidt
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 [0x719ee150]) (scratch:DI [ptr:0x719ee1

RTL frontend, insn recognition, and pointer equality

2016-10-19 Thread David Malcolm
I've updated the RTL frontend to the new "compact" dump format and have it "mostly working", for some definition of that term [1]. I'm focusing on the "__RTL" extension to cc1, rather than having a true "rtl1" frontend. I've run into an issue with insn recognition relating to pointer equality of