Re: [PATCH] Fix up make_compound_operation (PR rtl-optimization/57130)

2013-05-03 Thread Eric Botcazou
> Does it hurt to punt on nested SUBREG (it isn't really punting, just passing > SET instead of COMPARE, which means avoiding the and with power of two and > some make_extraction details), when usually the nested subregs should be > already simplified and thus the reason I want it there is just to

Re: [PATCH] Fix up make_compound_operation (PR rtl-optimization/57130)

2013-05-03 Thread Jakub Jelinek
On Fri, May 03, 2013 at 10:13:17AM +0200, Eric Botcazou wrote: > > My understanding is that in_code == COMPARE (as opposed to > > in_code == SET) is mostly harmless, just tells make_extraction > > to no longer special case zero extraction at position 0, but there is one > > exception - AND with con

Re: [PATCH] Fix up make_compound_operation (PR rtl-optimization/57130)

2013-05-03 Thread Eric Botcazou
> My understanding is that in_code == COMPARE (as opposed to > in_code == SET) is mostly harmless, just tells make_extraction > to no longer special case zero extraction at position 0, but there is one > exception - AND with constant power of two CONST_INT. > If we have > make_compound_operation (

[PATCH] Fix up make_compound_operation (PR rtl-optimization/57130)

2013-05-02 Thread Jakub Jelinek
Hi! As described in the PR, in some cases it is unsafe for make_compound_operation, if called with in_code == COMPARE, to pass through that value to make_compound_operation on the SUBREG_REG of a SUBREG. My understanding is that in_code == COMPARE (as opposed to in_code == SET) is mostly harmless