This patch introduces an improvement in the Alignment of the loads generated in createReplacementValues() by querying AAAlign attribute for the best Alignment for the base.
Note : No alignment implies natural alignment.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
You should query the base alignment AA in the initialize once to make sure it exists and is part of the fixpoint iteration. For now that is trivially the case but I can see that this might not be this way in the future.
llvm/lib/Transforms/IPO/Attributor.cpp | ||
---|---|---|
5666 | I think you can take the assumed alignment. |
Sry but you mean we should query the base in createInitialization right or you mean another initialization ?
Basictest.ll always make a strange problem with me sometimes the align of the load be 0 and from the condition I added it transform to 1, and in other times it gives align to the load with 4 value so why this could happen ?
another question isn't the default alignment is 1 which means there is no alignment why AAAlign tends sometimes to return 0, shouldn't it return 1 when no alignment available ?
My guess of the default alignment is because I saw MayBeAlign say that 1 means no alignment so is the case different ?
llvm/lib/Transforms/IPO/Attributor.cpp | ||
---|---|---|
5665–5668 | What happens if you just do MaybeAlign(AlignAA.getAssumedAlign())? |
llvm/lib/Transforms/IPO/Attributor.cpp | ||
---|---|---|
5665–5668 | some cases like argument promotion/attrs.ll returns 0 when query AAAlign attribute so that make it doesn't put any alignment to the load instr |
llvm/lib/Transforms/IPO/Attributor.cpp | ||
---|---|---|
5665–5668 | Oh, i see what you mean, no alignment implies natural alignment, not alignment of 1.. |
@courbet To be honest
explicit MaybeAlign(uint64_t Value) { assert((Value == 0 || llvm::isPowerOf2_64(Value)) && "Alignment is neither 0 nor a power of 2"); if (Value) emplace(Value); }
that if-check looks like a major rake.
llvm/lib/Transforms/IPO/Attributor.cpp | ||
---|---|---|
5665–5669 | I'd suggest rephrasing this to explain what is going on, something like // Alignment of 0 is treated by MaybeAlign as no alignment, // but when no alignment is specified for the load instruction, // natural alignment is assumed. So we have to manually bump it to 1. createReplacementValues(MaybeAlign(std::max(1, AlignAA.getAssumedAlign()), |
llvm/lib/Transforms/IPO/Attributor.cpp | ||
---|---|---|
5665–5669 | yes you are right we have to be more specific I will modify it sry :) also I forgot about the max function it is much cleaner :) |
llvm/lib/Transforms/IPO/Attributor.cpp | ||
---|---|---|
5668 | s/so when/but when/ |
If you always deal with defined alignment there is no need to use MaybeAlign.
Use Align in createReplacementValues (it will get rid of the extra if check).
Now, LoadInst::setAlignment takes a MaybeAlign but Align implicitly casts to MaybeAlign so you can safely pass in an Align (I'll optimize this case by providing setAlignment overloads later).
Then if you get raw alignment values that can be 0 but you assume that 0 means 1 use [assumeAligned](https://github.com/llvm/llvm-project/blob/ccf49b9ef012bab44b1f1322223e8b2e5ca89bad/llvm/include/llvm/Support/Alignment.h#L114).
Unfortunately the naming in this context is awkward (but that's how the API is supposed to be used) assumeAligned(AlignAA.getAssumedAlign()).
It will become better over time when AlignAA deals with Align/MaybeAlign directly.
I'm not sure what you mean here exactly. What do you think would be an appropriate check ?
I will try that thank you :)
llvm/test/Transforms/Attributor/ArgumentPromotion/basictest.ll | ||
---|---|---|
5 | Okay sry :) the problem I have in this test that it is not consistent to a certain value in alignment it sometimes gives alignment of 4 to the loads and sometimes it gives no alignment which I change to normal alignment (value of 1 ) , I will try to look further in this behaviour :) , but what could possibly result in that |
sry for late update, Hard times
Anyway I wanted to ask about a thing i noticed in AAPrivatizable attribute :
In this test :
define internal i32 @test(i32* %X, i32* %Y) { %A = load i32, i32* %X %B = load i32, i32* %Y %C = add i32 %A, %B ret i32 %C } define internal i32 @caller(i32* %B) { %A = alloca i32 store i32 1, i32* %A %C = call i32 @test(i32* %A, i32* %B) ret i32 %C } define i32 @callercaller() { %B = alloca i32 store i32 2, i32* %B %X = call i32 @caller(i32* %B) ret i32 %X }
and when i print the base used in loads in createReplacementValues function it prints :
%A = alloca i32 i32* B %B = alloca i32
and sometimes i run again and it prints :
%B = alloca i32 %A = alloca i32 %B.priv = alloca i32
and i think the base (i32* B) is wrong and it is a base that's because sometimes ACSRepairCB is invoked before FnRepairCB so the alloca instructions are not yet added so it gets the value of the base from the argument itself and not the alloca so isn't we should make sure that FnRepairCB is invoked before ACSRepairCB to make sure that not happens ?
So we privatize twice in this test. Apparently in non-deterministic order, which is bad and needs to be addressed. The question is, is one order "broken", if so why. I think what you can do is to precompute the AAAlign in manifest instead of doing this
Value *Base = ACS.getCallArgOperand(ARI.getReplacedArg().getArgNo()); which is order dependent.
Precompute the alignment for the loads in manifest and add test with different alignment privatizable arguments
I think what you can do is to precompute the AAAlign in manifest instead of doing this
That worked i think far more better than before, Thanks :)
LGTM, with a small nit. Can you update the diff and provide me with "Firstname Lastname <email>" so I can upload this for you?
llvm/lib/Transforms/IPO/Attributor.cpp | ||
---|---|---|
5342 | Make it an optional dependence (see the extra arguments of getAAFor) so we don't give up once we give up on the alignment. |
Sry for a lot of reformating patches, didn't know that i should rebuild clang format :)
My data :
Omar Ahmed <omarpirate2010@yahoo.com>
Make it an optional dependence (see the extra arguments of getAAFor) so we don't give up once we give up on the alignment.