On Mon, Jun 3, 2013 at 8:34 PM, Jeff Law <l...@redhat.com> wrote: > On 06/03/2013 12:32 PM, Kai Tietz wrote: >> >> 2013/6/3 Jeff Law <l...@redhat.com>: >>> >>> On 06/03/2013 11:00 AM, Richard Henderson wrote: >>>> >>>> >>>> On 06/03/2013 09:37 AM, Kai Tietz wrote: >>>>> >>>>> >>>>> foo: >>>>> .seh_endprologue >>>>> cmpb %cl, %dl >>>>> seta %al >>>>> ret >>>>> .seh_endproc >>>>> .p2align 4,,15 >>>>> .globl boo >>>>> .def boo; .scl 2; .type 32; .endef >>>>> .seh_proc boo >>>>> boo: >>>>> .seh_endprologue >>>>> movl %ecx, %eax >>>>> notl %eax >>>>> andl %edx, %eax >>>>> andl $1, %eax >>>>> ret >>>> >>>> >>>> >>>> Try arm or s390 or ppc for significantly different results. >>> >>> >>> I'm starting to wonder if we could delay make a choice about using a >>> relational or bit ops until gimple->rtl expansion. I haven't seen any >>> secondary benefits, so deferring to a later point where we might be able >>> to >>> query the backend's capabilities might make sense. >>> jeff >> >> >> Well, a secondary benefit I see in area of BC-optimization. But I >> agree that this operation should go along gimple->rtl transformation. >> And at same place BC-optimization should happen. > > Let's table it for now then. Ironically I was just looking at moving one of > the branch-cost transformations out of fold-const.c. We're going to have to > build out some infrastructure to make that happen. > > I'll withdraw the patch and just submit a missed optimization PR and xfailed > testsuite for this issue.
The transform is worthwhile if there is secondary benefit of being able to forward the result into a test instruction (GIMPLE_COND or condition in a COND_EXPR). Richard. > jeff
