This is an archive of the discontinued LLVM Phabricator instance.

[X86][Codegen] PR51615: don't replace wide volatile load with narrow broadcast-from-memory
ClosedPublic

Authored by lebedev.ri on Aug 26 2021, 4:07 AM.

Diff Detail

Event Timeline

lebedev.ri created this revision.Aug 26 2021, 4:07 AM
lebedev.ri requested review of this revision.Aug 26 2021, 4:07 AM
RKSimon added inline comments.Aug 26 2021, 4:15 AM
llvm/lib/Target/X86/X86ISelLowering.cpp
5049

Can you use normal and simple tests here?

just call the test file pr51615.ll - you gain nothing by having such a cumbersome filename

lebedev.ri added inline comments.Aug 26 2021, 4:52 AM
llvm/lib/Target/X86/X86ISelLowering.cpp
5049

We could, but i'm not sure we have to?
If the aligned load was already only loading a single element, why not promote it into broadcast?

Add one more test with non-missized volatile load.

spatel added inline comments.Aug 26 2021, 6:34 AM
llvm/lib/Target/X86/X86ISelLowering.cpp
5043–5046

This comment doesn't read clearly to me. The comment on the test does, so copy that here?

5049

We are already checking ISD::isNormalLoad() by calling MayFoldLoad() first, right?
MemSDNode::isSimple() would add a constraint for an atomic load. I'm not sure about the rules for those. A quick survey of existing uses suggests we do use that in general to be safe - see for example getBROADCAST_LOAD().

lebedev.ri marked an inline comment as done.

Deduplicate comments.

llvm/lib/Target/X86/X86ISelLowering.cpp
5049

I'm vary to change that without a testcast.
Right now verified rejects vector atomic loads:

atomic load operand must have integer, pointer, or floating point type!
 <2 x double>  %i = load atomic <2 x double>, <2 x double>* @g0 unordered, align 16

so i'm not sure if there is some thing bad wrt atomics.

spatel added inline comments.Aug 26 2021, 7:59 AM
llvm/lib/Target/X86/X86ISelLowering.cpp
5047

I'm not sure if the semantics on this are settled - what happens if the overall size matches, but the "shape" isn't the same?
I'm imagining something like:

%i = load volatile <2 x float>, <2 x float>* @test5_id12345, align 16
%b = bitcast <2 x float> %i to <1 x double>
%i1 = shufflevector <1 x double> %b, <1 x double> poison, <4 x i32> <i32 undef, i32 0, i32 undef, i32 0>
lebedev.ri added inline comments.Aug 26 2021, 8:07 AM
llvm/lib/Target/X86/X86ISelLowering.cpp
5047

I don't see why the "shape" would matter. it's either a single load of the same size or it's not.
https://llvm.org/docs/LangRef.html#volatile-memory-accesses notes

<...> the backend should never split or merge target-legal volatile load/store instructions. Similarly, IR-level volatile loads and stores cannot change from integer to floating-point or vice versa.

spatel added inline comments.Aug 26 2021, 8:27 AM
llvm/lib/Target/X86/X86ISelLowering.cpp
5047

It's that clause about changing types that raises the question. Ie, if it's not allowable to change from float to i32 for example, then is it also not allowable to change from <1 x double> to <1 x i64>?

The restriction seems to be limited to IR for some reason, so maybe it is irrelevant here, but seems worth adding another test, so we have some marker for current behavior.

lebedev.ri marked 2 inline comments as done.

Add another test as suggested by @spatel

spatel accepted this revision.Aug 26 2021, 8:34 AM

LGTM

This revision is now accepted and ready to land.Aug 26 2021, 8:34 AM
This revision was landed with ongoing or failed builds.Aug 26 2021, 8:47 AM
This revision was automatically updated to reflect the committed changes.

LGTM

Thank you for the review!