https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959

--- Comment #16 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Bill Schmidt from comment #14)
> We should definitely not be allowing the AltiVec "& ~16" flavors into these
> patterns.  I'm not certain whether your fix is the best way to achieve that,
> but it could well be; I'll defer to Segher on that.

So I _think_ the patch above is correct.  Ie, we shouldn't split the insn which
calls the rs6000_emit_le_vsx_* functions if the mem address isn't valid for the
patterns the splitter is going to create.

The question I have is, there are 2 expanders which I think we also need to
guard with similar tests.  They are vsx_load_<mode> and vsx_store_<mode>. 
Segher, I assume we want to verify we don't have an altivec style & ~16 address
there too, correct?  Just like we do in vector.md's mov<mode> pattern.

Reply via email to