On Fri, Nov 18, 2011 at 2:07 AM, Yuehai Du <duyue...@gmail.com> wrote: > 2011/11/18 Richard Guenther <richard.guent...@gmail.com>: >> On Thu, Nov 17, 2011 at 6:49 AM, Yuehai Du <duyue...@gmail.com> wrote: >>> 2011/11/17 Richard Guenther <richard.guent...@gmail.com>: >>>> On Wed, Nov 16, 2011 at 12:28 PM, Eric Botcazou <ebotca...@adacore.com> >>>> wrote: >>>>>> Huh, IVOPTs should never cause a different size memory read. I wonder >>>>>> if the original issue would still reproduce with the fix reverted. >>>>> >>>>> The original issue was unaligned arrays in packed structures. I don't >>>>> see what >>>>> could have changed since then. >>>> >>>> Ah, so it was expand being confused about the constructed access (not >>>> seeing >>>> a component-ref), thus the usual old issue we have there. There's indeed >>>> no >>>> trivial fix for this but to create the [TARGET_]MEM_REF with an explicitely >>>> unaligned type and hope that the target implements the movmisalign optab >>>> (the only case this explicit alignment is honored). And double-check the >>>> TARGET_MEM_REF expansion code properly duplicates the movmisalign >>>> path from the MEM_REF expander. >>>> >>>> I'd wish somebody fixed this path for non-movmisalign strict-align targets. >>>> >>> >>> I'm a little bit confused, and i don't know if i understand you correctly. >>> are you saying that we can remove those check in >>> find_interesting_uses_address, >>> and handle this misalign memory reference as aligned memory reference, >>> just attach the >>> misalign information in type and let expander to choose correct >>> expansion dependent on >>> movmisalign optab icode ? >> >> Yes. But only if movmisalign is available. >> >>> In that case if Target don't support misalign memory access, the >>> result of IVOPTS will >>> be non-optimal since the cost of IV used in misalign memory access is >>> wrong, right? >> >> No, the cost of the IV is the same, independent on whether it is aligned or >> not. >> >> Richard. > > I got you,thanks. > Would it be ok if i file a bug about this,like missed optimization > for misaligned > memory access in IVOPTS? > > and since the path for non-movmisalign strict-align targets don't > exist now, could i > add a condition in that check to avoid this. like: > > if (STRICT_ALIGNMENT && may_be_unaligned_p (base, step) > && optab_handler (movmisalign_optab, mode) == CODE_FOR_nothing) > goto fail; > > I don't know if it is appropriate to check optab in IVOPTS, sorry if > i go too far.
Yes, that's currently the only way. I'd rather eliminate this gap in expand though and simply go the bitfield expansion way there. Richard. > -- > Yuehai > >> >>> -- >>> Yuehai >>> >>> >>>> Richard. >>>> >>>>> -- >>>>> Eric Botcazou >>>>> >>>> >>> >> >
