This is the mail archive of the gcc-patches@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] |
On 09/10/2012 09:09 AM, Ian Bolton wrote: >> Can you send me the test case you were looking at for this? > > See attached. (Most of it is superfluous, but the point is that > we are not using the address to do a memory access.) Ok. Having dug a bit deeper I think the main problem is that you're working against yourself by not handling this pattern right from the beginning. You have split the address incorrectly to begin and are now trying to recover after the fact. The following patch seems to do the trick for me, producing > (insn 6 5 7 (set (reg:DI 81) > (high:DI (const:DI (plus:DI (symbol_ref:DI ("arr") [flags 0x80] <var_decl 0x7f9bae1105f0 arr>) > (const_int 12 [0xc]))))) z.c:8 -1 > (nil)) > > (insn 7 6 8 (set (reg:DI 80) > (lo_sum:DI (reg:DI 81) > (const:DI (plus:DI (symbol_ref:DI ("arr") [flags 0x80] <var_decl 0x7f9bae1105f0 arr>) > (const_int 12 [0xc]))))) z.c:8 -1 > (expr_list:REG_EQUAL (const:DI (plus:DI (symbol_ref:DI ("arr") [flags 0x80] <var_decl 0x7f9bae1105f0 arr>) > (const_int 12 [0xc]))) > (nil))) right from the .150.expand dump. I'll leave it to you to fully regression test and commit the patch as appropriate. ;-) r~
Attachment:
z
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |