No doubt there is a problem here somewhere, not sure if this is the best fix though or just hides it one level deeper.
I wonder if align(0) in the input is not already broken.
I'm trying to see if the Clang ppl are interested in changing the behavior that I think is at fault here: https://godbolt.org/z/jo4fx7
When we warn, we should not create the alignment assumption because in IR things depend on the fact that it is a power of two.
If we modify clang we should teach the verifier about the test case above and introduce an assertion isPowerOfTwo(RK.ArgValue).
Any updates on changing clang to avoid this?
There's a recent comment on:
...that suggests fuzzers have found their way to this crash too.
Wouldn't we still want this check in the optimizer given the text in LangRef?
"if the alignment is set to zero, the alignment of the function is set by the target to whatever it feels convenient":
I still believe clang should not generate non-power-of-two alignment in the assume (https://godbolt.org/z/zzd1hWc88). We don't allow non-power-of-two in almost any other place already, but here we somehow do.
The IR verifier needs to be updated, clang should issue an error, the webpage should mention the requirement (https://clang.llvm.org/docs/AttributeReference.html), and we would not needs this.
This looks like it's moving in the right direction.
Please split this up into clang change and a verifier change.
No, we should emit it as a simple assumption.
|4611–4619 ↗||(On Diff #364826)|
@jdoerfert Should second/third arguments be a *constant* integers ?
Thanks for the feedback. Sorry for misunderstanding, from earlier comments I thought that no llvm.assume should be emitted for non-power-of-2 alignments. Can you elaborate on what you mean by simple assumption should be emitted?
Sorry I didn't understand this comment and I haven't had time to revisit it to fully understand. I'm confused because if I remove the AA = nullptr; there's no change to clang and it will continue to generate an assume that the IR verifier is now being changed to reject.
e.g. in clang/test/CodeGen/non-power-of-2-alignment-assumptions.c
%call = call i8* @alloc(i32 7) call void @llvm.assume(i1 true) [ "align"(i8* %call, i64 7) ]
which would now be backend error: e.g
alignment must be a power of 2 call void @llvm.assume(i1 true) [ "align"(i8* %call, i64 7) ] in function t1 fatal error: error in backend: Broken function found, compilation aborted!
If you could explain what you would expect clang to emit in this case, I think that would help me and I can have another look.