[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