On Wed, Jul 18, 2012 at 5:39 PM, Ramana Radhakrishnan <ramana.radhakrish...@linaro.org> wrote: > On 18 July 2012 09:20, Carrot Wei <car...@google.com> wrote: >> On Tue, Jul 17, 2012 at 9:47 PM, Ramana Radhakrishnan >> <ramana.radhakrish...@linaro.org> wrote: >>> Carrot, >>> >>> Sorry about the delayed response. >>> >>> On 3 July 2012 12:28, Carrot Wei <car...@google.com> wrote: >>>> On Thu, Jun 28, 2012 at 12:14 AM, Ramana Radhakrishnan >>>> <ramana.radhakrish...@linaro.org> wrote: >>>>> On 28 May 2012 11:08, Carrot Wei <car...@google.com> wrote: >>>>>> Hi >>>>>> >>>>>> This is the second part of the patches that deals with 64bit and. It >>>>>> directly >>>>>> extends the patterns anddi3, anddi3_insn and anddi3_neon to handle 64bit >>>>>> constant operands. >>>>>> >>>>> >>>>> Comments about const_di_ok_for_op still apply from my review of your add >>>>> patch. >>>>> >>>>> However I don't see why and /ior / xor with constants that have either >>>>> the low or high parts set can't be expanded directly into ands of >>>>> subregs with moves of zero's or the original value especially if you >>>>> aren't looking at doing 64 bit operations in neon .With Neon being >>>>> used for 64 bit arithmetic it gets more interesting. >>>>> >>>>> Finally this should target PR target/53189. >>>>> >>>> >>>> Hi Ramana >>>> >>>> Thanks for the review. Following is the updated patch according to >>>> your comments. >>> >>> You've missed answering this part of my review :) >>> >>>>> However I don't see why and /ior / xor with constants that have either >>>>> the low or high parts set can't be expanded directly into ands of >>>>> subregs with moves of zero's or the original value especially if you >>>>> aren't looking at doing 64 bit operations in neon .With Neon being >>>>> used for 64 bit arithmetic it gets more interesting. >>> >> It has been handled by the const_ok_for_dimode_op and the output part >> of corresponding SI mode insn. Let's take the IOR case as an example. >> > > I noticed that - If I wasn't clear enough, the question was more > towards generating a subreg move at expand time rather than a split > and handling while outputting asm if you see what I mean. > I see your point now. I don't know how much better if we handle it earlier. Even if I generates subreg move for non-neon code at expand time, the latter output handling is still necessary for neon insns. Do you think it deserves the extra expand handling?
thanks Carrot
