[llvm-dev] [RFC] [X86] Emit unaligned vector moves on avx machine with option control.

via llvm-dev llvm-dev at lists.llvm.org
Mon Apr 19 10:18:36 PDT 2021


> >> So the application software is unchangeable, right?
> > Exactly right.  The application software works fine within itself.
> >
> > The system software, which we update roughly twice a year, also
> > accepted the misaligned data, until Clang was modified to emit the
> > aligned (trapping) opcodes.  We had to fix that so the system
> > software would continue to allow the (buggy but unchangeable)
> > application software to continue to work.
> >
> > Yes, it is indeed the case that we can update the system software
> > but not the game software.  I think it would be a distraction to
> > spell out the scenarios but please accept that it is the case.
> 
> Out of curiosity, why do you solve this in the backend rather than
> patching your frontend/headers to not specify alignment?  To my
> knowledge (which isn't great in this area), alignment of pointer
> arguments isn't part of the ABI.  Wouldn't tweaking the headers and
> simply recompiling your system libraries get you the same effect?

This is about the alignment of the pointed-to data... surely that is
a requirement that must be preserved?  I don't *think* the ABI says
anything to indicate pointed-to data cannot have alignment more than X.

I am not familiar with the component that is using this 32-byte-aligned
data structure, and can't say whether modifying it would be appropriate.
Toolchain was asked to address it; perhaps we could have pushed back,
but we didn't.

> p.s. The more you explain about your use case, the less motivating I
> find it for upstream.  This sounds like a weird situation you've created
> for yourselves and should bear the cost of maintaining the mitigation
> for.  Just as other downstream distributions do for other issues.  Just
> my 2 cents.

And in fact we decided not to upstream it, and we've lived with it (and
its fallout) for years.  The only reason I brought it up was because the
Intel folks were suggesting the same thing, and I thought it might be
worthwhile to describe motivating cases from Sony.

I would love to hear Intel's motivation, because it might be something
very different that would change all our minds.
--paulr



More information about the llvm-dev mailing list