[PATCH] D83360: [InstSimplify] Remove select ?, undef, X -> X and select ?, X, undef -> X

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

In D83360#2154584 , @echristo wrote:

> It's that even before the msan instrumentation the IR doesn't look correct - 
> thus a miscompile.


I'll share a prototype of the InstSimplify patch on Phabricator, in a day or 
two; it would be great if the miscompilation is fixed with the patch.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D83360/new/

https://reviews.llvm.org/D83360



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D83360: [InstSimplify] Remove select ?, undef, X -> X and select ?, X, undef -> X

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

In D83360#2162898 , @craig.topper 
wrote:

> @aqjune did you put a patch for InstSimplify doing distribution over undef 
> yet?


Sorry, making InstSimplify to safely distribute undef was a nontrivial job - 
other than updating InstSimplify to track uses, it needed rewinding folded 
undef records if simplification failed & update constant folding to track uses 
too. The folded value could be symbolic, making things more complex.
I'm trying an alternative solution for this problem, I will leave a link here 
after submission.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D83360/new/

https://reviews.llvm.org/D83360



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D83360: [InstSimplify] Remove select ?, undef, X -> X and select ?, X, undef -> X

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

Made a patch at https://reviews.llvm.org/D84250 .


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D83360/new/

https://reviews.llvm.org/D83360



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D81678: Introduce partialinit attribute at call sites for stricter poison analysis

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

Hi, this is really interesting. I was interested in statically analyzing 
whether a value is undef/poison, so I also thought about the existence of this 
attribute, but I never imagined that MSan would benefit from this attribute as 
well.

> The partialinit attribute is, in some sense, backwards: the definition is 
> essentially "an argument *not* marked partialinit must not contain any poison 
> values". We usually try to avoid negative reasoning like this; I'm afraid 
> it'll make transforms harder to reason about.



> An alternative is to invert the meaning of the attribute and put it on all 
> arguments that must be not poison. Those are a lot more common though.

I agree with these two opinions. IIUC, in LLVM IR, attaching attribute to an 
argument imposes more restriction to the value.
Changing the semantics of IR to raise UB when poison or undef is passed to a 
function call will affect soundness of optimizations as well: for example, 
function outlining or dead arg elimination can introduce such function calls.
If the change is big, maybe we can split the patch to (1) implement the 
attribute (2) enable adding the attribute, so (2) contains all the big & 
mechanical diffs.

> @efriedma 
>  The way that call argument coercion works is unsound in the presence of 
> poison. An integer can't be partially poisoned: it's either poison, or not 
> poison. We probably need to come up with some safer way to pass 
> structs/unions.

This is true, clang frontend may lower an argument with aggregate type into one 
with large int type (such as i64).
However, can poison value be safely generated in C? Paddings or union with 
different size may contain undef bits, but not poison. Signed overflow is UB.
Undef value can exist bitwisely, so I think this is an orthogonal issue.

> @rsmith 
> It's not entirely clear to me what partialinit means. Does it mean that some 
> bytes of the parameter might be undef / poison? Or does it mean that some 
> bytes of the parameter that (for a struct parameter or array thereof) 
> correspond to a struct member might be undef / poison? (Eg, if I pass a { i8, 
> i32 } to a function, do we need to explicitly say that the three padding 
> bytes are not initialized?)

For poison, I believe it is now used as a valuewise concept in LLVM, so if the 
argument is a non-aggregate type such as i32/float/i8* it should be just binary 
(whether it is poison or not).

If it is agreed that we should have inverted version of `partialinit`, I'd like 
to suggest calling it `frozen` instead... :)
We have the notion of frozen value in LangRef already: it is used as e.g. `the 
branch condition should be frozen, otherwise it is undefined behavior`.
If an argument is frozen, it does not have any undef bits or poison value.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81678/new/

https://reviews.llvm.org/D81678



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D81678: Introduce partialinit attribute at call sites for stricter poison analysis

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

In D81678#2091089 , @eugenis wrote:

> Positive attribute sounds good to me (frozen is not a bad name), but the 
> tests update change is going to be huge. Any concerns about IR size bloat? 
> The attribute will apply to the majority of function arguments, 8 bytes per 
> instance as far as I can see.


Hi,

The issue stems from the difference between whether passing poison/undef to fn 
arg is allowed in C and IR, so (to add a positive attribute) increase in diff 
and # of attributes will happen, the question is how we can make the increase 
as small as possible.
To minimize diff, what about additionally introducing a function-level 
attribute such as `args_frozen` stating that all arguments are frozen. (e.g 
`define void @f(i32 x, i32 y) args_frozen`)?
The attribute will appear at the end of the line, so many CHECK of function 
signatures will still pass. (e.g. clang/test/CodeGen/mips64-padding-arg.c )


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81678/new/

https://reviews.llvm.org/D81678



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D83360: [InstSimplify] Remove select ?, undef, X -> X and select ?, X, undef -> X

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

Seems like a bug in instsimplify:

  define i1 @f(i32 %x, i32 %y) {
%cmp9.not.1 = icmp eq i32 %x, %y
%cmp15  = icmp slt i32 %x, %y
%spec.select39 = select i1 %cmp9.not.1, i1 undef, i1 %cmp15
%spec.select40 = xor i1 %cmp9.not.1, 1
%spec.select  = and i1 %spec.select39, %spec.select40
ret i1 %spec.select
  }
  =>
  define i1 @f(i32 %x, i32 %y) {
%cmp9.not.1 = icmp eq i32 %x, %y
%cmp15 = icmp slt i32 %x, %y
%spec.select39 = select i1 %cmp9.not.1, i1 undef, i1 %cmp15
ret i1 %spec.select39
  }

https://godbolt.org/z/a8f7hT

Alive2 says it's incorrect: https://alive2.llvm.org/ce/z/-8Q4HL

Seems to be related with ValueTracking's isImpliedCondition since this 
optimizations happens only when operands of the two icmps are the same.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D83360/new/

https://reviews.llvm.org/D83360



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D83360: [InstSimplify] Remove select ?, undef, X -> X and select ?, X, undef -> X

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

(renaming variables for readability)

  %a = select i1 %s, i1 undef, i1 %t
  %b = xor i1 %s, 1
  %c = and i1 %a, %b

This series of reasoning happened from a single SimplifyAndInst call:

  c = a & (s ^ 1)
= (a & s) ^ (a & 1); ExpandBinOp
= ((select s, undef, t) & s) ^ a
= (select s, (undef & s), (t & s)) ^ a ; ThreadBinOpOverSelect
= (select s, (undef & s), false) ^ a   ; since s = (x == y), t = (x < y)
= (select s, false, false) ^ a ; choose undef to be false
= a
= select s, undef, t

In general, distributing `a` into operands of xor (second line) isn't sound 
because it increases the number of uses of `a`. We don't want to totally 
disable the simplification, however.

If InstSimplify never increases the number of uses in the end, we have an 
alternative solution: tracking to which value undef is folded.
Whenever an undef value is chosen to be a concrete value, the decision should 
be remembered, so the copied undefs won't be folded into different values.
In case of InstSimplify, we can identify individual undefs by Use, since 
InstSimplify won't do any transformation inside.
This means SimplifyXXX needs to return two things: the simplified value & the 
undef cache. Since InstSimplify isn't designed to do transformation directly, 
other optimizations like InstCombine should perform the final change.

Does this solution make sense? Then, I can prepare a patch for this.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D83360/new/

https://reviews.llvm.org/D83360



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D81678: Introduce frozen attribute at call sites for stricter poison analysis

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune accepted this revision.
aqjune added a comment.
This revision is now accepted and ready to land.

For the LangRef part, LGTM modulo the suggested change. Could anyone review 
clang and LLVM's updated part?




Comment at: llvm/docs/LangRef.rst:1644
+and return values. When ``"frozen"`` is present, every bit of the
+tagged type is fully initialized and never poison.
 ``"probe-stack"``

Could you explicitly state that if it is aggregate or vector type all elements 
and paddings should be frozen too?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81678/new/

https://reviews.llvm.org/D81678



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D81678: Introduce partialinit attribute at call sites for stricter poison analysis

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

In D81678#2099444 , @efriedma wrote:

> So I guess we've discussed the following alternatives so far:
>
> (snip)
>
> Maybe (1) is the least-bad; all the others compromise by making LLVM harder 
> to understand.  We can make porting the clang tests easier by adding a cc1 
> flag to turn off emitting frozen attributes, I guess (so instead of updating 
> the CHECK lines, you could just mechanically update the RUN line).




In D81678#2099591 , @eugenis wrote:

> I agree that (1) is the easiest to work with and the least error-prone, and 
> that's what we must shoot for in the design. We could do (4) later as an 
> optimization.


I agree. After going to (1) we can bring optimizations as a follow-up if it 
needed. I vote for the -cc1 option as a workaround.
BTW, was there a case in the past that needed a massive updates in tests as 
well? I wonder how it was addressed at that time.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81678/new/

https://reviews.llvm.org/D81678



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D81678: Introduce frozen attribute at call sites for stricter poison analysis

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

In D81678#2105077 , @eugenis wrote:

> > Could you explicitly state that if it is aggregate or vector type all 
> > elements and paddings should be frozen too?
>
> If an aggregate is passed as an aggregate at IR level, we should not care 
> about the padding.
>  Unless it's coerced to an integer.


Oh sorry, I missed the comment of @guiand above.
I wanted to suggest making things simpler by having its memory representation 
always have well-defined bits if stored into memory.
But, if it is helpful for MSan's performance because it is well-defined in C, I 
think it is fine to not care about the paddings.
I suggest explicitly mentioning that we're not considering paddings of 
aggregates in the LangRef (at the definition of frozen value too if you want; 
actually I thought it was already described in the definition, but it didn't).

In D81678#2105429 , @jdoerfert wrote:

> I'm unsure if we want the name `frozen` as it is less helpful to anyone now 
> familiar with the frozen instruction.
>  In a different thread we concluded that we need some sort of `nopoison` as 
> an attribute to convey the behavior is UB if the value would be poison.
>  I would very much prefer a self explanatory spelling here, especially since 
> `nopoison` will be derived from sources other than the frozen instruction.


In the nonnull thread I was in favor of `nopoison` as well, but became to think 
that `nopoison` is a bit misleading in this patch because it doesn't talk about 
undef bit.
Personally I preferred `frozen` because whenever there is an ambiguity in its 
semantics, the precise definition can be made by simply updating the notion of 
a frozen value, but if a more intuitive spelling is consideration I'm open to 
any suggestions.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81678/new/

https://reviews.llvm.org/D81678



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D85345: [BuildLibCalls] Add noundef to standard I/O functions

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune updated this revision to Diff 284246.
aqjune added a comment.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Update PR3589-freestanding-libcalls.c


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D85345/new/

https://reviews.llvm.org/D85345

Files:
  clang/test/CodeGen/PR3589-freestanding-libcalls.c
  llvm/lib/Transforms/Utils/BuildLibCalls.cpp
  llvm/test/CodeGen/X86/no-plt-libcalls.ll
  llvm/test/Transforms/InferFunctionAttrs/annotate.ll

Index: llvm/test/Transforms/InferFunctionAttrs/annotate.ll
===
--- llvm/test/Transforms/InferFunctionAttrs/annotate.ll
+++ llvm/test/Transforms/InferFunctionAttrs/annotate.ll
@@ -352,19 +352,19 @@
 ; CHECK: declare x86_fp80 @fabsl(x86_fp80) [[G0]]
 declare x86_fp80 @fabsl(x86_fp80)
 
-; CHECK: declare i32 @fclose(%opaque* nocapture) [[G1]]
+; CHECK: declare noundef i32 @fclose(%opaque* nocapture noundef) [[G1]]
 declare i32 @fclose(%opaque*)
 
-; CHECK: declare noalias %opaque* @fdopen(i32, i8* nocapture readonly) [[G1]]
+; CHECK: declare noalias noundef %opaque* @fdopen(i32 noundef, i8* nocapture noundef readonly) [[G1]]
 declare %opaque* @fdopen(i32, i8*)
 
-; CHECK: declare i32 @feof(%opaque* nocapture) [[G1]]
+; CHECK: declare noundef i32 @feof(%opaque* nocapture noundef) [[G1]]
 declare i32 @feof(%opaque*)
 
-; CHECK: declare i32 @ferror(%opaque* nocapture) [[G2]]
+; CHECK: declare noundef i32 @ferror(%opaque* nocapture noundef) [[G2]]
 declare i32 @ferror(%opaque*)
 
-; CHECK: declare i32 @fflush(%opaque* nocapture) [[G1]]
+; CHECK: declare noundef i32 @fflush(%opaque* nocapture noundef) [[G1]]
 declare i32 @fflush(%opaque*)
 
 ; CHECK: declare i32 @ffs(i32) [[G0]]
@@ -376,19 +376,19 @@
 ; CHECK: declare i32 @ffsll(i64) [[G0]]
 declare i32 @ffsll(i64)
 
-; CHECK: declare i32 @fgetc(%opaque* nocapture) [[G1]]
+; CHECK: declare noundef i32 @fgetc(%opaque* nocapture noundef) [[G1]]
 declare i32 @fgetc(%opaque*)
 
-; CHECK: declare i32 @fgetpos(%opaque* nocapture, i64* nocapture) [[G1]]
+; CHECK: declare noundef i32 @fgetpos(%opaque* nocapture noundef, i64* nocapture noundef) [[G1]]
 declare i32 @fgetpos(%opaque*, i64*)
 
-; CHECK: declare i8* @fgets(i8*, i32, %opaque* nocapture) [[G1]]
+; CHECK: declare noundef i8* @fgets(i8* noundef, i32 noundef, %opaque* nocapture noundef) [[G1]]
 declare i8* @fgets(i8*, i32, %opaque*)
 
-; CHECK: declare i32 @fileno(%opaque* nocapture) [[G1]]
+; CHECK: declare noundef i32 @fileno(%opaque* nocapture noundef) [[G1]]
 declare i32 @fileno(%opaque*)
 
-; CHECK: declare void @flockfile(%opaque* nocapture) [[G1]]
+; CHECK: declare void @flockfile(%opaque* nocapture noundef) [[G1]]
 declare void @flockfile(%opaque*)
 
 ; CHECK: declare double @floor(double) [[G0]]
@@ -436,19 +436,19 @@
 ; CHECK: declare x86_fp80 @fmodl(x86_fp80, x86_fp80) [[G0]]
 declare x86_fp80 @fmodl(x86_fp80, x86_fp80)
 
-; CHECK: declare noalias %opaque* @fopen(i8* nocapture readonly, i8* nocapture readonly) [[G1]]
+; CHECK: declare noalias noundef %opaque* @fopen(i8* nocapture noundef readonly, i8* nocapture noundef readonly) [[G1]]
 declare %opaque* @fopen(i8*, i8*)
 
-; CHECK: declare i32 @fprintf(%opaque* nocapture, i8* nocapture readonly, ...) [[G1]]
+; CHECK: declare noundef i32 @fprintf(%opaque* nocapture noundef, i8* nocapture noundef readonly, ...) [[G1]]
 declare i32 @fprintf(%opaque*, i8*, ...)
 
-; CHECK: declare i32 @fputc(i32, %opaque* nocapture) [[G1]]
+; CHECK: declare noundef i32 @fputc(i32 noundef, %opaque* nocapture noundef) [[G1]]
 declare i32 @fputc(i32, %opaque*)
 
-; CHECK: declare i32 @fputs(i8* nocapture readonly, %opaque* nocapture) [[G1]]
+; CHECK: declare noundef i32 @fputs(i8* nocapture noundef readonly, %opaque* nocapture noundef) [[G1]]
 declare i32 @fputs(i8*, %opaque*)
 
-; CHECK: declare i64 @fread(i8* nocapture, i64, i64, %opaque* nocapture) [[G1]]
+; CHECK: declare noundef i64 @fread(i8* nocapture noundef, i64 noundef, i64 noundef, %opaque* nocapture noundef) [[G1]]
 declare i64 @fread(i8*, i64, i64, %opaque*)
 
 ; CHECK: declare void @free(i8* nocapture) [[G3:#[0-9]+]]
@@ -463,61 +463,61 @@
 ; CHECK: declare x86_fp80 @frexpl(x86_fp80, i32* nocapture) [[G1]]
 declare x86_fp80 @frexpl(x86_fp80, i32*)
 
-; CHECK: declare i32 @fscanf(%opaque* nocapture, i8* nocapture readonly, ...) [[G1]]
+; CHECK: declare noundef i32 @fscanf(%opaque* nocapture noundef, i8* nocapture noundef readonly, ...) [[G1]]
 declare i32 @fscanf(%opaque*, i8*, ...)
 
-; CHECK: declare i32 @fseek(%opaque* nocapture, i64, i32) [[G1]]
+; CHECK: declare noundef i32 @fseek(%opaque* nocapture noundef, i64 noundef, i32 noundef) [[G1]]
 declare i32 @fseek(%opaque*, i64, i32)
 
-; CHECK: declare i32 @fseeko(%opaque* nocapture, i64, i32) [[G1]]
+; CHECK: declare noundef i32 @fseeko(%opaque* nocapture noundef, i64 noundef, i32 noundef) [[G1]]
 declare i32 @fseeko(%opaque*, i64, i32)
 
-; CHECK-LINUX: declare i32 @fseeko64(%opaque* noca

[PATCH] D85345: [BuildLibCalls] Add noundef to standard I/O functions

[Juneyoung Lee via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGef018cb65c98: [BuildLibCalls] Add noundef to standard I/O 
functions (authored by aqjune).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D85345/new/

https://reviews.llvm.org/D85345

Files:
  clang/test/CodeGen/PR3589-freestanding-libcalls.c
  llvm/lib/Transforms/Utils/BuildLibCalls.cpp
  llvm/test/CodeGen/X86/no-plt-libcalls.ll
  llvm/test/Transforms/InferFunctionAttrs/annotate.ll

Index: llvm/test/Transforms/InferFunctionAttrs/annotate.ll
===
--- llvm/test/Transforms/InferFunctionAttrs/annotate.ll
+++ llvm/test/Transforms/InferFunctionAttrs/annotate.ll
@@ -352,19 +352,19 @@
 ; CHECK: declare x86_fp80 @fabsl(x86_fp80) [[G0]]
 declare x86_fp80 @fabsl(x86_fp80)
 
-; CHECK: declare i32 @fclose(%opaque* nocapture) [[G1]]
+; CHECK: declare noundef i32 @fclose(%opaque* nocapture noundef) [[G1]]
 declare i32 @fclose(%opaque*)
 
-; CHECK: declare noalias %opaque* @fdopen(i32, i8* nocapture readonly) [[G1]]
+; CHECK: declare noalias noundef %opaque* @fdopen(i32 noundef, i8* nocapture noundef readonly) [[G1]]
 declare %opaque* @fdopen(i32, i8*)
 
-; CHECK: declare i32 @feof(%opaque* nocapture) [[G1]]
+; CHECK: declare noundef i32 @feof(%opaque* nocapture noundef) [[G1]]
 declare i32 @feof(%opaque*)
 
-; CHECK: declare i32 @ferror(%opaque* nocapture) [[G2]]
+; CHECK: declare noundef i32 @ferror(%opaque* nocapture noundef) [[G2]]
 declare i32 @ferror(%opaque*)
 
-; CHECK: declare i32 @fflush(%opaque* nocapture) [[G1]]
+; CHECK: declare noundef i32 @fflush(%opaque* nocapture noundef) [[G1]]
 declare i32 @fflush(%opaque*)
 
 ; CHECK: declare i32 @ffs(i32) [[G0]]
@@ -376,19 +376,19 @@
 ; CHECK: declare i32 @ffsll(i64) [[G0]]
 declare i32 @ffsll(i64)
 
-; CHECK: declare i32 @fgetc(%opaque* nocapture) [[G1]]
+; CHECK: declare noundef i32 @fgetc(%opaque* nocapture noundef) [[G1]]
 declare i32 @fgetc(%opaque*)
 
-; CHECK: declare i32 @fgetpos(%opaque* nocapture, i64* nocapture) [[G1]]
+; CHECK: declare noundef i32 @fgetpos(%opaque* nocapture noundef, i64* nocapture noundef) [[G1]]
 declare i32 @fgetpos(%opaque*, i64*)
 
-; CHECK: declare i8* @fgets(i8*, i32, %opaque* nocapture) [[G1]]
+; CHECK: declare noundef i8* @fgets(i8* noundef, i32 noundef, %opaque* nocapture noundef) [[G1]]
 declare i8* @fgets(i8*, i32, %opaque*)
 
-; CHECK: declare i32 @fileno(%opaque* nocapture) [[G1]]
+; CHECK: declare noundef i32 @fileno(%opaque* nocapture noundef) [[G1]]
 declare i32 @fileno(%opaque*)
 
-; CHECK: declare void @flockfile(%opaque* nocapture) [[G1]]
+; CHECK: declare void @flockfile(%opaque* nocapture noundef) [[G1]]
 declare void @flockfile(%opaque*)
 
 ; CHECK: declare double @floor(double) [[G0]]
@@ -436,19 +436,19 @@
 ; CHECK: declare x86_fp80 @fmodl(x86_fp80, x86_fp80) [[G0]]
 declare x86_fp80 @fmodl(x86_fp80, x86_fp80)
 
-; CHECK: declare noalias %opaque* @fopen(i8* nocapture readonly, i8* nocapture readonly) [[G1]]
+; CHECK: declare noalias noundef %opaque* @fopen(i8* nocapture noundef readonly, i8* nocapture noundef readonly) [[G1]]
 declare %opaque* @fopen(i8*, i8*)
 
-; CHECK: declare i32 @fprintf(%opaque* nocapture, i8* nocapture readonly, ...) [[G1]]
+; CHECK: declare noundef i32 @fprintf(%opaque* nocapture noundef, i8* nocapture noundef readonly, ...) [[G1]]
 declare i32 @fprintf(%opaque*, i8*, ...)
 
-; CHECK: declare i32 @fputc(i32, %opaque* nocapture) [[G1]]
+; CHECK: declare noundef i32 @fputc(i32 noundef, %opaque* nocapture noundef) [[G1]]
 declare i32 @fputc(i32, %opaque*)
 
-; CHECK: declare i32 @fputs(i8* nocapture readonly, %opaque* nocapture) [[G1]]
+; CHECK: declare noundef i32 @fputs(i8* nocapture noundef readonly, %opaque* nocapture noundef) [[G1]]
 declare i32 @fputs(i8*, %opaque*)
 
-; CHECK: declare i64 @fread(i8* nocapture, i64, i64, %opaque* nocapture) [[G1]]
+; CHECK: declare noundef i64 @fread(i8* nocapture noundef, i64 noundef, i64 noundef, %opaque* nocapture noundef) [[G1]]
 declare i64 @fread(i8*, i64, i64, %opaque*)
 
 ; CHECK: declare void @free(i8* nocapture) [[G3:#[0-9]+]]
@@ -463,61 +463,61 @@
 ; CHECK: declare x86_fp80 @frexpl(x86_fp80, i32* nocapture) [[G1]]
 declare x86_fp80 @frexpl(x86_fp80, i32*)
 
-; CHECK: declare i32 @fscanf(%opaque* nocapture, i8* nocapture readonly, ...) [[G1]]
+; CHECK: declare noundef i32 @fscanf(%opaque* nocapture noundef, i8* nocapture noundef readonly, ...) [[G1]]
 declare i32 @fscanf(%opaque*, i8*, ...)
 
-; CHECK: declare i32 @fseek(%opaque* nocapture, i64, i32) [[G1]]
+; CHECK: declare noundef i32 @fseek(%opaque* nocapture noundef, i64 noundef, i32 noundef) [[G1]]
 declare i32 @fseek(%opaque*, i64, i32)
 
-; CHECK: declare i32 @fseeko(%opaque* nocapture, i64, i32) [[G1]]
+; CHECK: declare noundef i32 @fseeko(%opaque* nocapture noundef, i64 noundef, i32 noundef) [[G1]]
 declare i32 @fseeko(%opaque*, i64

[PATCH] D85345: [BuildLibCalls] Add noundef to standard I/O functions

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

If things go well, I'll add noundef to other library functions such as utime, 
setenv, unsetenv,  as well.
For malloc/calloc/realloc/free, I'll think more about them. I guess it is safe 
to tag noundef to free's operand, but for malloc I'm not 100% sure...


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D85345/new/

https://reviews.llvm.org/D85345

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D85345: [BuildLibCalls] Add noundef to standard I/O functions

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

What about undef or poison is given to malloc? If it should raise UB, the size 
argument and returned pointer should be noundef.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D85345/new/

https://reviews.llvm.org/D85345

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D85345: [BuildLibCalls] Add noundef to standard I/O functions

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

In D85345#2205745 , @jdoerfert wrote:

> In D85345#2205712 , @aqjune wrote:
>
>> What about undef or poison is given to malloc? If it should raise UB, the 
>> size argument and returned pointer should be noundef.
>
> It is unclear to me if we want to forbid undef to be passed to malloc. It 
> makes practical sense but not from a semantic perspective.
> However, even if you pass undef you should not get undef back. So the return 
> should never be undef for sure. If it doesn, how could you ever deal with it, 
> given that a branch on the result would be UB :D

Makes sense and labeling the returned pointer of malloc as noundef will be 
useful in various places, e.g. proving safety of loop unswitching on 
`icmp(malloc(p), null)`.
Give me some time, because I'd like to play with this by implementing this on 
Alive2 and see how it goes when running unit tests.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D85345/new/

https://reviews.llvm.org/D85345

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D79636: [LangRef] Clarify the semantics of the `byval` attribute

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

I have a minor question:

> a call of a readnone function with a byval argument is not classified as 
> readnone (which it is today: https://godbolt.org/z/dDfQ5r)

%0 at caller has readnone attribute - is it related with the propagation of 
readnone attribute from %0 of empty function to the caller?
Some comments above seems to be related with this question, but I rather wonder 
about the validity of the propagation of readnone in this example.

Actually I wonder whether things will become clearer if an alloca-and-copy (or 
something that is equivalent with this) is explicitly used to show the behavior 
of pass-as-value rather than byval implicitly encoding the behavior; my 
impression is that byval is different from other attributes like readnone or 
nonnull, because it isn't the result of value analysis. This will be a lot of 
work though...


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79636/new/

https://reviews.llvm.org/D79636



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D103874: [IR] Rename the shufflevector's undef mask to poison

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

In D103874#3594617 , @aqjune wrote:

> It seems llvm/lib/Target/X86/X86ISelLowering.cpp's LowerAVXCONCAT_VECTORS is 
> relevant to efficient lowering of `shufflevector %x, freeze(poison), mask`.

After patching `LowerAVXCONCAT_VECTORS`, lowering 
https://github.com/llvm/llvm-project/blob/main/llvm/test/CodeGen/X86/avx-intrinsics-fast-isel.ll#L257
 generates:

  vblendps  $15, %ymm0, %ymm0, %ymm0

To make it fully no-op, tablegen files must be edited. I gave it a try, `.td` 
compiled successfully, but weirdly - perhaps due to either incorrect use of 
tablegen's pattern matcher or some hidden rule that I didn't address - 
`vblendps` is still there. The written patch is as follows:
https://github.com/aqjune/llvm-project/commit/b4393e36b33ca08ce77ae662479ceaf9a76eab8b

One of relevant, edited parts:

  // llvm/lib/Target/X86/X86InstrVecCompiler.td
def : Pat<(VT (insert_subvector undef, subRC:$src, (iPTR 0))),
  (VT (INSERT_SUBREG (IMPLICIT_DEF), subRC:$src, subIdx))>;
  +
  +  def : Pat<(VT (insert_subvector (freeze undef), subRC:$src, (iPTR 0))),
  +(VT (INSERT_SUBREG (IMPLICIT_DEF), subRC:$src, subIdx))>;

I spent some time but couldn't figure out why it does not work.
Can someone tell me whether the pattern matching is being correctly used? Any 
help is appreciated.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103874/new/

https://reviews.llvm.org/D103874

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D103874: [IR] Rename the shufflevector's undef mask to poison

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

In D103874#3611483 , @nikic wrote:

> Which intrinsic are you working on here? If this is about the mm_undefined 
> intrinsics, why do we need to change those from the current status quo of 
> using a zero value instead of undef?

It is about the `mm256_castpd128_pd256` intrinsic and its friends 
(clang/test/CodeGen/X86/avx-builtins.c, line 146).
It was previously using `shufflevector` with undef masks - since the results 
are poison, an alternative pattern as below is necessary to represent the 
intrinsic:

  %a1 = freeze <2 x double> poison
  %res = shufflevector <2 x double> %a0, <2 x double> %a1, <4 x i32> 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103874/new/

https://reviews.llvm.org/D103874

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D103874: [IR] Rename the shufflevector's undef mask to poison

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

PR31524 (https://github.com/llvm/llvm-project/issues/31524) discusses about the 
lowering of such intrinsics.
According to the PR, it seems users consider undefined intrinsics as returning 
unknown but consistent bits.

If it works, my updates in the draft 
(https://github.com/aqjune/llvm-project/commit/b4393e36b33ca08ce77ae662479ceaf9a76eab8b)
 will improve backends dealing with freeze(poison), which will help lowering 
`_mm256_cast*` with zero copy.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103874/new/

https://reviews.llvm.org/D103874

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D85788: [Clang test] Update to allow passing extra default clang arguments in use_clang

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.
Herald added a subscriber: frasercrmck.

In D85788#2335838 , @eugenis wrote:

> I wonder it can be avoided by
>
> - disable noundef analysis by default in cc1
> - always add -enable-noundef-analysis in the driver when invoking cc1

Would this cause more tests that use `%clang` to be updated, such as  
`test/CodeGen/mips-vector-return.c`?
IIUC, the tests in this patch are okay to have their `%clang` replaced with 
`%clang_bin` because they are not checking function signatures.

> I don't like the %clang_bin substitution - imho it's unclear for the test 
> authors when to use it instead of %clang, but I can't come up with a better 
> idea.

From a user's perspective, simply naming it as `%clang_noundef` would be 
clearer, IMO.
This new substitution is going to be used for the noundef checks in D81678 
 only anyway.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D85788/new/

https://reviews.llvm.org/D85788

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D81678: Introduce noundef attribute at call sites for stricter poison analysis

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

In D81678#2438264 , @eugenis wrote:

> This change looks fine to me, but I'm slightly concerned about 
> https://reviews.llvm.org/D85788 - see my last comment on that revision.

Thank you for the link! I left a comment there.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81678/new/

https://reviews.llvm.org/D81678

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D85788: [Clang test] Update to allow passing extra default clang arguments in use_clang

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

In D85788#2444136 , @guiand wrote:

> IMO it's better to just one-and-done programatically add `-Xclang 
> -disable-noundef-analysis` to all the tests' RUN lines. That way there are no 
> hidden flags.

If a script for this can be written and people who are working for the 
downstream project are happy with the script, this is the best approach IMO. It 
is clear and explicit.

In D85788#2441457 , @eugenis wrote:

>> This new substitution is going to be used for the noundef checks in D81678 
>>  only anyway.
>
> I'm not sure what you mean by this. The substitution is used ~380 times in 
> this patch alone.
> In the future, any attempt to use %clang -### or -%clang -cc1as will produce 
> the same unused argument warning, and it is very unclear that is can be fixed 
> with %clang_bin. Note that code search for "-disable-noundef-analysis" does 
> NOT lead you to the definition of %clang_bin!

I see, I was naively thinking the `%clang` -> `%clang_bin` changes were here to 
simply show that they are equivalent if function signatures are not checked. I 
thought `%clang` could be still used for those tests.
But they were here because the upcoming patch will otherwise make them raise 
unused argument warning.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D85788/new/

https://reviews.llvm.org/D85788

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D93586: [InstCombine] use poison as placeholder for undemanded elems

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

In D93586#2464841 , @spatel wrote:

> Besides changing IRBuilder and shufflevector's definition, I think we'll also 
> need updates in the vectorizers, InstSimplify, and other places in 
> InstCombine that use UndefValue for InsertElement and shuffle transforms.

Thank you for the pointer!

> Do you have an estimate of how many tests are out there? If it's a temporary 
> increase and not huge, I don't think there is much downside. But if we think 
> the transition will take a long time, then maybe we don't want the 
> duplication.

Using this command (which counts `insertelement <..> undef` in non-checks):

  grep -R -E '^[^;]*insertelement <.*> undef,' . | cut -d":" -f1 | uniq | wc -l

There are 792 files in llvm/test, most of which are in test/Transform (119) and 
test/CodeGen(655).
The transition will be swiftly done (if there's no other issue hopefully) by 
the next weekend.

My concern is that some tests aren't using `utils/update_test_checks.py`, and 
this makes things complicated. :(
Simply replacing `insertelement undef` at `CHECK:` isn't enough (ex: 
Transforms/SLPVectorizer/X86/alternate-cast.ll).
What do you think?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93586/new/

https://reviews.llvm.org/D93586

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D93586: [InstCombine] use poison as placeholder for undemanded elems

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

In D93586#2466284 , @aqjune wrote:

> The transition will be swiftly done (if there's no other issue hopefully) by 
> the next weekend.

Oops, I meant this weekend hopefully.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93586/new/

https://reviews.llvm.org/D93586

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D93586: [InstCombine] use poison as placeholder for undemanded elems

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

> There are 792 files in llvm/test, most of which are in test/Transform (119) 
> and test/CodeGen(655).
> The transition will be swiftly done (if there's no other issue hopefully) by 
> the next weekend.

Thinking about these again, do we need to make a poison copy for test/CodeGen? 
I don't think so, since the backend won't be changed anyway.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93586/new/

https://reviews.llvm.org/D93586

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D93586: [InstCombine] use poison as placeholder for undemanded elems

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

In D93586#2467844 , @RKSimon wrote:

> I'm sorry I've only just started looking at this - are you saying that you 
> want to handle all "insertelement undef" cases in one go and not just a 
> series of patcches after this one?

It will be treated in a series of patches. There are places other than 
SimplifyDemandedVectorElts that create `insertelement undef`. I'll create these 
and link them as children.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93586/new/

https://reviews.llvm.org/D93586

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D93586: [InstCombine] use poison as placeholder for undemanded elems

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

In D93586#2468350 , @spatel wrote:

> It would be good to update those for consistency; the codegen tests are 
> supposed to be representative of what comes out of the IR optimizer. IIUC, we 
> could do the substitution on those files already, and it would not change 
> anything. But let's sort out the IR changes first?

Yep, let's start with IR changes first. I made undef->poison test commits 
already.

> In D93586#2466284 , @aqjune wrote:
>
>> 
>
> Yes, tests that don't have scripted CHECK lines require more work to 
> understand. That SLP test file is scripted though. Is there another problem 
> with that one?

Oh, I simply meant that replacing "insertelement undef" with "insertelement 
poison" won't work when updating CHECK part of non-scripted tests.
It seems things are okay because there aren't too many tests needed to be fixed.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93586/new/

https://reviews.llvm.org/D93586

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D93793: [IR] Let IRBuilder's CreateVectorSplat use poison as inselt's placeholder

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune created this revision.
aqjune added reviewers: spatel, lebedev.ri, efriedma, nlopes, regehr, RKSimon, 
zhengyangl, nikic, hfinkel.
Herald added subscribers: dmgreen, kbarton, hiraditya, nemanjai.
aqjune requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

This patch updates IRBuilder to create insertelement using poison when creating 
a vector splat.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D93793

Files:
  clang/test/CodeGen/SystemZ/zvector.c
  clang/test/CodeGen/arm-mve-intrinsics/compare.c
  clang/test/CodeGen/arm-mve-intrinsics/cplusplus.cpp
  clang/test/CodeGen/arm-mve-intrinsics/dup.c
  clang/test/CodeGen/arm-mve-intrinsics/ternary.c
  clang/test/CodeGen/arm-mve-intrinsics/vaddq.c
  clang/test/CodeGen/arm-mve-intrinsics/vhaddq.c
  clang/test/CodeGen/arm-mve-intrinsics/vhsubq.c
  clang/test/CodeGen/arm-mve-intrinsics/vmulq.c
  clang/test/CodeGen/arm-mve-intrinsics/vqaddq.c
  clang/test/CodeGen/arm-mve-intrinsics/vqdmulhq.c
  clang/test/CodeGen/arm-mve-intrinsics/vqdmullbq.c
  clang/test/CodeGen/arm-mve-intrinsics/vqdmulltq.c
  clang/test/CodeGen/arm-mve-intrinsics/vqrdmulhq.c
  clang/test/CodeGen/arm-mve-intrinsics/vqsubq.c
  clang/test/CodeGen/arm-mve-intrinsics/vsubq.c
  clang/test/CodeGen/builtins-ppc-p10vector.c
  clang/test/CodeGen/matrix-type-operators.c
  clang/test/CodeGen/vecshift.c
  clang/test/CodeGenCXX/matrix-type-operators.cpp
  clang/test/CodeGenCXX/vector-conditional.cpp
  clang/test/CodeGenCXX/vector-splat-conversion.cpp
  clang/test/CodeGenOpenCL/bool_cast.cl
  clang/test/CodeGenOpenCL/shifts.cl
  llvm/lib/IR/IRBuilder.cpp
  llvm/test/Transforms/InstCombine/X86/x86-vector-shifts-inseltpoison.ll
  llvm/test/Transforms/InstCombine/X86/x86-vector-shifts.ll
  llvm/test/Transforms/InstCombine/gep-inbounds-null.ll
  llvm/test/Transforms/InstCombine/getelementptr.ll
  llvm/test/Transforms/InstCombine/vscale_cmp.ll
  
llvm/test/Transforms/LoopVectorize/AArch64/outer_loop_test1_no_explicit_vect_width.ll
  llvm/test/Transforms/LoopVectorize/ARM/mve-gather-scatter-tailpred.ll
  llvm/test/Transforms/LoopVectorize/ARM/mve-reduction-types.ll
  llvm/test/Transforms/LoopVectorize/ARM/pointer_iv.ll
  llvm/test/Transforms/LoopVectorize/X86/consecutive-ptr-uniforms.ll
  llvm/test/Transforms/LoopVectorize/X86/constant-fold.ll
  llvm/test/Transforms/LoopVectorize/X86/cost-model-assert.ll
  llvm/test/Transforms/LoopVectorize/X86/invariant-load-gather.ll
  llvm/test/Transforms/LoopVectorize/X86/invariant-store-vectorization.ll
  llvm/test/Transforms/LoopVectorize/X86/load-deref-pred.ll
  llvm/test/Transforms/LoopVectorize/X86/metadata-enable.ll
  llvm/test/Transforms/LoopVectorize/X86/optsize.ll
  
llvm/test/Transforms/LoopVectorize/X86/outer_loop_test1_no_explicit_vect_width.ll
  llvm/test/Transforms/LoopVectorize/X86/pr34438.ll
  llvm/test/Transforms/LoopVectorize/X86/small-size.ll
  llvm/test/Transforms/LoopVectorize/X86/tail_loop_folding.ll
  llvm/test/Transforms/LoopVectorize/X86/uniform_mem_op.ll
  llvm/test/Transforms/LoopVectorize/X86/vect.omp.force.small-tc.ll
  
llvm/test/Transforms/LoopVectorize/X86/x86-interleaved-accesses-masked-group.ll
  llvm/test/Transforms/LoopVectorize/dont-fold-tail-for-const-TC.ll
  llvm/test/Transforms/LoopVectorize/dont-fold-tail-for-divisible-TC.ll
  llvm/test/Transforms/LoopVectorize/first-order-recurrence-complex.ll
  llvm/test/Transforms/LoopVectorize/float-induction.ll
  llvm/test/Transforms/LoopVectorize/float-minmax-instruction-flag.ll
  llvm/test/Transforms/LoopVectorize/if-pred-stores.ll
  llvm/test/Transforms/LoopVectorize/induction-step.ll
  llvm/test/Transforms/LoopVectorize/induction.ll
  llvm/test/Transforms/LoopVectorize/interleaved-accesses.ll
  llvm/test/Transforms/LoopVectorize/invariant-store-vectorization.ll
  llvm/test/Transforms/LoopVectorize/minmax_reduction.ll
  llvm/test/Transforms/LoopVectorize/multiple-strides-vectorization.ll
  llvm/test/Transforms/LoopVectorize/optsize.ll
  llvm/test/Transforms/LoopVectorize/outer_loop_test1.ll
  llvm/test/Transforms/LoopVectorize/outer_loop_test2.ll
  llvm/test/Transforms/LoopVectorize/pr39417-optsize-scevchecks.ll
  llvm/test/Transforms/LoopVectorize/pr44488-predication.ll
  llvm/test/Transforms/LoopVectorize/pr46525-expander-insertpoint.ll
  
llvm/test/Transforms/LoopVectorize/scalable-loop-unpredicated-body-scalar-tail.ll
  llvm/test/Transforms/LoopVectorize/select-reduction.ll
  llvm/test/Transforms/LoopVectorize/vector-geps.ll
  llvm/test/Transforms/LowerMatrixIntrinsics/bigger-expressions-double.ll
  llvm/test/Transforms/LowerMatrixIntrinsics/const-gep.ll
  
llvm/test/Transforms/LowerMatrixIntrinsics/multiply-add-sub-double-row-major.ll
  llvm/test/Transforms/LowerMatrixIntrinsics/multiply-double-contraction-fmf.ll
  llvm/test/Transforms/LowerMatrixIntrinsics/multiply-double-contraction.ll
  llvm/test/Transforms/LowerMatrixIntrinsics/multiply-double-row-major.ll
  llvm/test/Transforms/LowerMatrixI

[PATCH] D93793: [IR] Let IRBuilder's CreateVectorSplat use poison as inselt's placeholder

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added inline comments.



Comment at: llvm/lib/IR/IRBuilder.cpp:1021
   Value *Zeros = ConstantAggregateZero::get(VectorType::get(I32Ty, EC));
   return CreateShuffleVector(V, Undef, Zeros, Name + ".splat");
 }

nlopes wrote:
> while at it, don't you want to change this one to poison as well?
It would be great, but there are many other places that create shufflevector 
with undef args (InstCombineCalls, etc). Since this and related patches are big 
changes, I think it might be good to land these first.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93793/new/

https://reviews.llvm.org/D93793

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D93586: [InstCombine] use poison as placeholder for undemanded elems

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

I'll make two more patches - the instsimplify/vectorizer/ changes that make 
insertelement poison, and the langref update to shufflevector.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93586/new/

https://reviews.llvm.org/D93586

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D90275: [clang][IR] Add support for leaf attribute

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

Hi,

Naming is a hard thing... I have no special preference. :/

However, I'd like to understand the details of this attribute.

Would LTO be affected because `leaf` is guaranteed to untouch the current 
translation unit only?

  // a.c
  int x;
  void f1() {
f2();
  }
  void g() { x = 3; }
  
  // b.c
  void f2() {
leaf();
  }
  
  // leaf.c
  attribute((leaf)) void leaf() {
g();
  }

IIUC this program is okay because the caller of leaf() is at a.c, not b.c.
But, let's assume that a.c and b.c are LTO-ed, and leaf.c is separately 
compiled.
If LTO merges a.c and b.c into the same module, the two TUs cannot be 
distinguished anymore; either `leaf` should be dropped, or LTO should somehow 
conceptually keep two TUs.
Would it be a valid concern? Then I think it should be mentioned.

Another question is more about the motivation of this attribute (well, I know 
it is introduced by gcc first; just throwing a question :) )
If the motivation is to support better data flow analysis, is there something 
special in callback itself?
The gcc document states that `sin()` is a leaf function, and IIUC this is 
because `sin()` never touches the memory allocated at caller's TU (because 
`errno` isn't at the caller's TU).
I think things are easier if we simply say that `leaf` cannot touch the memory 
of current TU, regardless of the existence of callbacks.
Is there something important in the callback itself?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D90275/new/

https://reviews.llvm.org/D90275

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D90275: [clang][IR] Add support for leaf attribute

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

In D90275#2371813 , @jdoerfert wrote:

> As noted by the GCC docs, it doesn't mean anything on a definition so that 
> you can safely merge TUs. I want us to forbid `leaf` on IR function 
> definitions for that reason, it would not mean anything and be only confusing.

Okay, I see.
I agree that having this attribute at definitions is slightly dangerous..!

But I am not still 100% sure about the safety of merging... I see that it is 
okay when `leaf` is on a definition, but what about declaration?

  // a.ll
  define void f1() { f2(); }
  define void g() { x = 3; }
  // b.ll
  define void f2() { leaf(); }
  declare leaf void @leaf() ; If @leaf() was actually calling @g(), is merging 
a.ll and b.ll valid?



> It is not a memory thing. However, the "almost" matching memory property is 
> called `inaccesiblememonly` so that is why I wanted to call this 
> `inaccessiblecodeonly`.

Eh, actually my question was more like a question to gcc people about why 
`leaf` was defined that way. Maybe my question is not relevant in this thread. 
Thank you for answering though.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D90275/new/

https://reviews.llvm.org/D90275

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D90275: [clang][IR] Add support for leaf attribute

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

In D90275#2374648 , @gulfem wrote:

> Leaf attribute is specifically intended for library functions and I think all 
> the existing usage of leaf attribute is in the library function declarations.
> For ex, it is only used in syscalls in Fuchsia.
> Therefore, I'm not sure whether it is really necessary to ban leaf attribute 
> in function definitions.
> Even though function attributes are typically intended to be used in the 
> function declaration, compilers do not have policy to forbid using them in 
> the function definition.

Maybe it's because the `leaf` (or `nocallback` or whatever) attribute at the 
function definition in IR can't be used for any optimization?
For the callers, `leaf` attribute at the function declarations is already 
giving the information.
But the attribute at function definitions really give no additional information 
inside the TU, so it's redundant.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D90275/new/

https://reviews.llvm.org/D90275

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D82317: [Clang/Test]: Update tests where `noundef` attribute is necessary

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.
Herald added a subscriber: frasercrmck.

In D82317#2201215 , @rjmccall wrote:

> second, it's yet another contribution towards the giant pile of attributes 
> that seem to have become necessary to do any work in LLVM

I don't think this is true. There are a few optimizations disabled (either 
fully or conditionally) because it is incorrect when its input is undefined 
(D85765 , D85684 
, a few optimizations in SimplifyCFG). There 
are even optimizations that are incorrect w.r.t. undef but still running simply 
because removing all of them isn't practical.
Giving a guarantee that a value is well defined is very helpful because these 
optimizations can be revived.
Currently, there is no such guarantee in function boundaries because it is 
legal to pass undef to a function argument. This explains dead argument 
elimination and function outlining (which may introduce fn call with undef).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D82317/new/

https://reviews.llvm.org/D82317

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D86841: [clang] Add mustprogress and llvm.loop.mustprogress attribute deduction

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added inline comments.



Comment at: clang/lib/CodeGen/CGStmt.cpp:801
+ getLangOpts().CPlusPlus11 || getLangOpts().CPlusPlus14 ||
+ getLangOpts().CPlusPlus17 || getLangOpts().C2x) {
+LoopMustProgress = true;

A silly question: does old C/C++ not guarantee that loops should make forward 
progress?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86841/new/

https://reviews.llvm.org/D86841

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D81678: Introduce noundef attribute at call sites for stricter poison analysis

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

I think it makes sense - IIUC, for most of the clang tests, noundef won't be 
the attribute of interest.
For brevity of tests, I think the change is fine.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81678/new/

https://reviews.llvm.org/D81678

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D88979: [InstCombine] combineLoadToOperationType(): don't fold int<->ptr cast into load

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

+1 for this patch!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88979/new/

https://reviews.llvm.org/D88979

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D91055: [clang-tidy] Introduce misc No Integer To Pointer Cast check

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added inline comments.



Comment at: clang-tools-extra/docs/clang-tidy/checks/misc-no-inttoptr.rst:12
+if you got that integral value via a pointer-to-integer cast originally,
+the new pointer will lack the provenance information from the original pointer.
+

aaron.ballman wrote:
> Does this run afoul of the C++ standard's requirements for pointer 
> traceability: http://eel.is/c++draft/basic.stc.dynamic.safety ?
This is fine because the compiled IR is allowed to be more defined than the C++ 
source.

In C++, accessing a pointer that is derived from an integer is UB if it is 
out-of-bounds location of the object pointed by the integer.
In LLVM IR (I mean in the suggested memory model), it is relaxed to have 
well-defined behavior if the pointer is pointing to a different, but in-bounds 
location of an object.
This loses the precision of points-to analysis if inttoptr is involved, but 
makes more arithmetic optimizations on integers valid.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D91055/new/

https://reviews.llvm.org/D91055

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D92270: [ConstantFold] Fold more operations to poison

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune updated this revision to Diff 308200.
aqjune added a comment.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

update clang/test/Frontend/fixed_point_unary.c

It seems unsigned _Fract type can only represent [0.0, 1.0)? I tried to find a 
relevant sentence from 
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf , but couldn't.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D92270/new/

https://reviews.llvm.org/D92270

Files:
  clang/test/Frontend/fixed_point_unary.c
  llvm/lib/IR/ConstantFold.cpp
  llvm/test/CodeGen/AMDGPU/amdgpu-codegenprepare-fold-binop-select.ll
  llvm/test/Transforms/InstCombine/apint-shift.ll
  llvm/test/Transforms/InstCombine/canonicalize-ashr-shl-to-masking.ll
  llvm/test/Transforms/InstCombine/canonicalize-lshr-shl-to-masking.ll
  llvm/test/Transforms/InstCombine/canonicalize-shl-lshr-to-masking.ll
  llvm/test/Transforms/InstCombine/icmp.ll
  
llvm/test/Transforms/InstCombine/partally-redundant-left-shift-input-masking-after-truncation-variant-a.ll
  
llvm/test/Transforms/InstCombine/partally-redundant-left-shift-input-masking-after-truncation-variant-b.ll
  
llvm/test/Transforms/InstCombine/partally-redundant-left-shift-input-masking-after-truncation-variant-c.ll
  
llvm/test/Transforms/InstCombine/partally-redundant-left-shift-input-masking-after-truncation-variant-d.ll
  
llvm/test/Transforms/InstCombine/partally-redundant-left-shift-input-masking-after-truncation-variant-e.ll
  
llvm/test/Transforms/InstCombine/partally-redundant-left-shift-input-masking-variant-a.ll
  
llvm/test/Transforms/InstCombine/partally-redundant-left-shift-input-masking-variant-b.ll
  
llvm/test/Transforms/InstCombine/partally-redundant-left-shift-input-masking-variant-c.ll
  
llvm/test/Transforms/InstCombine/partally-redundant-left-shift-input-masking-variant-d.ll
  
llvm/test/Transforms/InstCombine/partally-redundant-left-shift-input-masking-variant-e.ll
  llvm/test/Transforms/InstCombine/select-of-bittest.ll
  llvm/test/Transforms/InstCombine/shift-add.ll
  llvm/test/Transforms/InstSimplify/ConstProp/InsertElement.ll
  llvm/test/Transforms/InstSimplify/ConstProp/cast.ll
  llvm/test/Transforms/InstSimplify/ConstProp/poison.ll
  llvm/test/Transforms/InstSimplify/ConstProp/shift.ll
  llvm/test/Transforms/InstSimplify/ConstProp/vector-undef-elts.ll
  llvm/test/Transforms/InstSimplify/ConstProp/vscale.ll
  llvm/test/Transforms/InstSimplify/div.ll
  llvm/test/Transforms/InstSimplify/rem.ll
  llvm/test/Transforms/InstSimplify/undef.ll
  llvm/test/Transforms/SROA/phi-gep.ll
  llvm/test/Transforms/SROA/select-gep.ll
  llvm/test/Transforms/VectorCombine/X86/insert-binop-with-constant.ll
  llvm/test/Transforms/VectorCombine/X86/insert-binop.ll
  llvm/unittests/IR/ConstantsTest.cpp

Index: llvm/unittests/IR/ConstantsTest.cpp
===
--- llvm/unittests/IR/ConstantsTest.cpp
+++ llvm/unittests/IR/ConstantsTest.cpp
@@ -27,7 +27,7 @@
   Constant* Zero = ConstantInt::get(Int1, 0);
   Constant* NegOne = ConstantInt::get(Int1, static_cast(-1), true);
   EXPECT_EQ(NegOne, ConstantInt::getSigned(Int1, -1));
-  Constant* Undef = UndefValue::get(Int1);
+  Constant* Poison = PoisonValue::get(Int1);
 
   // Input:  @b = constant i1 add(i1 1 , i1 1)
   // Output: @b = constant i1 false
@@ -53,21 +53,21 @@
   // @g = constant i1 false
   EXPECT_EQ(Zero, ConstantExpr::getSub(One, One));
 
-  // @h = constant i1 shl(i1 1 , i1 1)  ; undefined
-  // @h = constant i1 undef
-  EXPECT_EQ(Undef, ConstantExpr::getShl(One, One));
+  // @h = constant i1 shl(i1 1 , i1 1)  ; poison
+  // @h = constant i1 poison
+  EXPECT_EQ(Poison, ConstantExpr::getShl(One, One));
 
   // @i = constant i1 shl(i1 1 , i1 0)
   // @i = constant i1 true
   EXPECT_EQ(One, ConstantExpr::getShl(One, Zero));
 
-  // @j = constant i1 lshr(i1 1, i1 1)  ; undefined
-  // @j = constant i1 undef
-  EXPECT_EQ(Undef, ConstantExpr::getLShr(One, One));
+  // @j = constant i1 lshr(i1 1, i1 1)  ; poison
+  // @j = constant i1 poison
+  EXPECT_EQ(Poison, ConstantExpr::getLShr(One, One));
 
-  // @m = constant i1 ashr(i1 1, i1 1)  ; undefined
-  // @m = constant i1 undef
-  EXPECT_EQ(Undef, ConstantExpr::getAShr(One, One));
+  // @m = constant i1 ashr(i1 1, i1 1)  ; poison
+  // @m = constant i1 poison
+  EXPECT_EQ(Poison, ConstantExpr::getAShr(One, One));
 
   // @n = constant i1 mul(i1 -1, i1 1)
   // @n = constant i1 true
@@ -218,7 +218,6 @@
   Constant *Elt = ConstantInt::get(Int16Ty, 2015);
   Constant *Poison16 = PoisonValue::get(Int16Ty);
   Constant *Undef64  = UndefValue::get(Int64Ty);
-  Constant *UndefV16 = UndefValue::get(P6->getType());
   Constant *PoisonV16 = PoisonValue::get(P6->getType());
 
   #define P0STR "ptrtoint (i32** @dummy to i32)"
@@ -295,8 +294,8 @@
 
   EXPECT_EQ(Elt, ConstantExpr::getExtractElement(
  ConstantExpr::getInsertElement(P6, Elt, One), One));
-  EXPECT_EQ(UndefV16, ConstantExpr:

[PATCH] D92270: [ConstantFold] Fold more operations to poison

[Juneyoung Lee via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG53040a968dc2: [ConstantFold] Fold more operations to poison 
(authored by aqjune).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D92270/new/

https://reviews.llvm.org/D92270

Files:
  clang/test/Frontend/fixed_point_unary.c
  llvm/lib/IR/ConstantFold.cpp
  llvm/test/CodeGen/AMDGPU/amdgpu-codegenprepare-fold-binop-select.ll
  llvm/test/Transforms/InstCombine/apint-shift.ll
  llvm/test/Transforms/InstCombine/canonicalize-ashr-shl-to-masking.ll
  llvm/test/Transforms/InstCombine/canonicalize-lshr-shl-to-masking.ll
  llvm/test/Transforms/InstCombine/canonicalize-shl-lshr-to-masking.ll
  llvm/test/Transforms/InstCombine/icmp.ll
  
llvm/test/Transforms/InstCombine/partally-redundant-left-shift-input-masking-after-truncation-variant-a.ll
  
llvm/test/Transforms/InstCombine/partally-redundant-left-shift-input-masking-after-truncation-variant-b.ll
  
llvm/test/Transforms/InstCombine/partally-redundant-left-shift-input-masking-after-truncation-variant-c.ll
  
llvm/test/Transforms/InstCombine/partally-redundant-left-shift-input-masking-after-truncation-variant-d.ll
  
llvm/test/Transforms/InstCombine/partally-redundant-left-shift-input-masking-after-truncation-variant-e.ll
  
llvm/test/Transforms/InstCombine/partally-redundant-left-shift-input-masking-variant-a.ll
  
llvm/test/Transforms/InstCombine/partally-redundant-left-shift-input-masking-variant-b.ll
  
llvm/test/Transforms/InstCombine/partally-redundant-left-shift-input-masking-variant-c.ll
  
llvm/test/Transforms/InstCombine/partally-redundant-left-shift-input-masking-variant-d.ll
  
llvm/test/Transforms/InstCombine/partally-redundant-left-shift-input-masking-variant-e.ll
  llvm/test/Transforms/InstCombine/select-of-bittest.ll
  llvm/test/Transforms/InstCombine/shift-add.ll
  llvm/test/Transforms/InstSimplify/ConstProp/InsertElement.ll
  llvm/test/Transforms/InstSimplify/ConstProp/cast.ll
  llvm/test/Transforms/InstSimplify/ConstProp/poison.ll
  llvm/test/Transforms/InstSimplify/ConstProp/shift.ll
  llvm/test/Transforms/InstSimplify/ConstProp/vector-undef-elts.ll
  llvm/test/Transforms/InstSimplify/ConstProp/vscale.ll
  llvm/test/Transforms/InstSimplify/div.ll
  llvm/test/Transforms/InstSimplify/rem.ll
  llvm/test/Transforms/InstSimplify/undef.ll
  llvm/test/Transforms/SROA/phi-gep.ll
  llvm/test/Transforms/SROA/select-gep.ll
  llvm/test/Transforms/VectorCombine/X86/insert-binop-with-constant.ll
  llvm/test/Transforms/VectorCombine/X86/insert-binop.ll
  llvm/unittests/IR/ConstantsTest.cpp

Index: llvm/unittests/IR/ConstantsTest.cpp
===
--- llvm/unittests/IR/ConstantsTest.cpp
+++ llvm/unittests/IR/ConstantsTest.cpp
@@ -27,7 +27,7 @@
   Constant* Zero = ConstantInt::get(Int1, 0);
   Constant* NegOne = ConstantInt::get(Int1, static_cast(-1), true);
   EXPECT_EQ(NegOne, ConstantInt::getSigned(Int1, -1));
-  Constant* Undef = UndefValue::get(Int1);
+  Constant* Poison = PoisonValue::get(Int1);
 
   // Input:  @b = constant i1 add(i1 1 , i1 1)
   // Output: @b = constant i1 false
@@ -53,21 +53,21 @@
   // @g = constant i1 false
   EXPECT_EQ(Zero, ConstantExpr::getSub(One, One));
 
-  // @h = constant i1 shl(i1 1 , i1 1)  ; undefined
-  // @h = constant i1 undef
-  EXPECT_EQ(Undef, ConstantExpr::getShl(One, One));
+  // @h = constant i1 shl(i1 1 , i1 1)  ; poison
+  // @h = constant i1 poison
+  EXPECT_EQ(Poison, ConstantExpr::getShl(One, One));
 
   // @i = constant i1 shl(i1 1 , i1 0)
   // @i = constant i1 true
   EXPECT_EQ(One, ConstantExpr::getShl(One, Zero));
 
-  // @j = constant i1 lshr(i1 1, i1 1)  ; undefined
-  // @j = constant i1 undef
-  EXPECT_EQ(Undef, ConstantExpr::getLShr(One, One));
+  // @j = constant i1 lshr(i1 1, i1 1)  ; poison
+  // @j = constant i1 poison
+  EXPECT_EQ(Poison, ConstantExpr::getLShr(One, One));
 
-  // @m = constant i1 ashr(i1 1, i1 1)  ; undefined
-  // @m = constant i1 undef
-  EXPECT_EQ(Undef, ConstantExpr::getAShr(One, One));
+  // @m = constant i1 ashr(i1 1, i1 1)  ; poison
+  // @m = constant i1 poison
+  EXPECT_EQ(Poison, ConstantExpr::getAShr(One, One));
 
   // @n = constant i1 mul(i1 -1, i1 1)
   // @n = constant i1 true
@@ -218,7 +218,6 @@
   Constant *Elt = ConstantInt::get(Int16Ty, 2015);
   Constant *Poison16 = PoisonValue::get(Int16Ty);
   Constant *Undef64  = UndefValue::get(Int64Ty);
-  Constant *UndefV16 = UndefValue::get(P6->getType());
   Constant *PoisonV16 = PoisonValue::get(P6->getType());
 
   #define P0STR "ptrtoint (i32** @dummy to i32)"
@@ -295,8 +294,8 @@
 
   EXPECT_EQ(Elt, ConstantExpr::getExtractElement(
  ConstantExpr::getInsertElement(P6, Elt, One), One));
-  EXPECT_EQ(UndefV16, ConstantExpr::getInsertElement(P6, Elt, Two));
-  EXPECT_EQ(UndefV16, ConstantExpr::getInsertElement(P6, Elt, Big));
+  EXPECT_EQ(PoisonV16, Constant

[PATCH] D92270: [ConstantFold] Fold more operations to poison

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

Hi,

It seems it is related to two optimizations:
(1) `select i1 x, true, y` -> `or i1 x, y`
(2) `or i1 x, poison` -> `poison`

Semantically, the first one is broken. It needs to freeze y. But, it will 
introduce a lot of freeze instructions. The clang patches that introduce 
noundef to function arguments is still ongoing.
Another workaround is to weaken (2) to `or i1 x, poison` -> `x`. This fixes the 
miscompilation; I'll push a commit that does this.

  --- a/llvm/lib/IR/ConstantFold.cpp
  +++ b/llvm/lib/IR/ConstantFold.cpp
  @@ -1105,7 +1105,10 @@ Constant *llvm::ConstantFoldBinaryInstruction(unsigned 
Opcode, Constant *C1,
 }
   
 // Binary operations propagate poison.
  -  if (isa(C1) || isa(C2))
  +  bool PoisonFold = !C1->getType()->isIntegerTy(1) || 
  +  (Opcode != Instruction::Or && Opcode != Instruction::And &&
  +   Opcode != Instruction::Xor);
  +  if (PoisonFold && (isa(C1) || isa(C2)))
   return PoisonValue::get(C1->getType());
   
 // Handle scalar UndefValue and scalable vector UndefValue. Fixed-length


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D92270/new/

https://reviews.llvm.org/D92270

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D92270: [ConstantFold] Fold more operations to poison

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

In D92270#2422661 , @uabelho wrote:

> Should langref also be updated to describe this? Or does it already?
> I just found this
>  "An instruction that depends on a poison value, produces a poison value 
> itself."
> here
>  http://llvm.org/docs/LangRef.html#poison-values

I think "Values other than phi nodes and select instructions depend on their 
operands." was supposed to say that. :)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D92270/new/

https://reviews.llvm.org/D92270

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D81678: Introduce noundef attribute at call sites for stricter poison analysis

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

Hello all,
What is the status of this patch?
Do we need someone who look into the lit change?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81678/new/

https://reviews.llvm.org/D81678

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D92270: [ConstantFold] Fold more operations to poison

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

In D92270#2538713 , @RKSimon wrote:

> https://bugs.llvm.org/show_bug.cgi?id=49005 seems to be due to this (either 
> directly or it has unearthed an existing problem)

I reverted this commit; I'll reland this after the underlying problem is 
resolved.
I'll push the revert commit to 12.x branch as well.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D92270/new/

https://reviews.llvm.org/D92270

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D93817: [InstCombine] Update transformations to use poison for insertelement/shufflevector's placeholder value (2/2)

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune abandoned this revision.
aqjune added a comment.

I abandon this patch because (1) shufflevector parts are covered in D110226 
, D110227 , 
D110230 , and (2) insertelement parts will be 
covered in upcoming new patches.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93817/new/

https://reviews.llvm.org/D93817

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D94380: [InstCombine] Update transformations to use poison for insertelement/shufflevector's placeholder value (1/2)

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune abandoned this revision.
aqjune added a comment.

I abandon this patch because (1) shufflevector parts are covered in D110226 
, D110227 , 
D110230 , and (2) insertelement parts will be 
covered in upcoming new patches.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D94380/new/

https://reviews.llvm.org/D94380

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D103874: [IR] Rename the shufflevector's undef mask to poison

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune updated this revision to Diff 375094.
aqjune added a comment.
Herald added a subscriber: arphaman.

Rebase


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103874/new/

https://reviews.llvm.org/D103874

Files:
  clang/test/CodeGen/X86/avx-builtins.c
  clang/test/CodeGen/X86/avx512f-builtins.c
  clang/test/CodeGen/builtins-ppc-p10vector.c
  clang/test/CodeGen/builtins-ppc-p9vector.c
  clang/test/CodeGen/builtinshufflevector2.c
  clang/test/CodeGen/ext-vector.c
  clang/test/CodeGenOpenCL/as_type.cl
  clang/test/CodeGenOpenCL/partial_initializer.cl
  clang/test/CodeGenOpenCL/preserve_vec3.cl
  clang/test/CodeGenOpenCL/vector_literals.cl
  clang/test/CodeGenOpenCL/vector_shufflevector.cl
  llvm/include/llvm-c/Core.h
  llvm/include/llvm/IR/Instructions.h
  llvm/lib/Analysis/InstructionSimplify.cpp
  llvm/lib/Analysis/ValueTracking.cpp
  llvm/lib/IR/AsmWriter.cpp
  llvm/lib/IR/ConstantFold.cpp
  llvm/lib/IR/Core.cpp
  llvm/lib/IR/Instructions.cpp
  llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp
  llvm/lib/Transforms/InstCombine/InstCombineSelect.cpp
  llvm/lib/Transforms/InstCombine/InstCombineSimplifyDemanded.cpp
  llvm/lib/Transforms/InstCombine/InstCombineVectorOps.cpp
  llvm/lib/Transforms/InstCombine/InstructionCombining.cpp
  llvm/lib/Transforms/Scalar/ScalarizeMaskedMemIntrin.cpp
  llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
  llvm/lib/Transforms/Vectorize/VectorCombine.cpp
  llvm/test/Analysis/CostModel/AMDGPU/shufflevector.ll
  llvm/test/Analysis/CostModel/X86/reduction.ll
  llvm/test/Analysis/CostModel/X86/shuffle-extract_subvector.ll
  llvm/test/Analysis/CostModel/X86/shuffle-insert_subvector.ll
  llvm/test/Analysis/CostModel/X86/shuffle-single-src.ll
  llvm/test/CodeGen/AMDGPU/rewrite-out-arguments.ll
  llvm/test/CodeGen/Generic/expand-experimental-reductions.ll
  llvm/test/CodeGen/PowerPC/arg_promotion.ll
  llvm/test/Transforms/CodeGenPrepare/X86/x86-shuffle-sink-inseltpoison.ll
  llvm/test/Transforms/CodeGenPrepare/X86/x86-shuffle-sink.ll
  llvm/test/Transforms/DeadStoreElimination/masked-dead-store-inseltpoison.ll
  llvm/test/Transforms/DeadStoreElimination/masked-dead-store.ll
  
llvm/test/Transforms/InstCombine/AMDGPU/amdgcn-demanded-vector-elts-inseltpoison.ll
  llvm/test/Transforms/InstCombine/AMDGPU/amdgcn-demanded-vector-elts.ll
  llvm/test/Transforms/InstCombine/X86/x86-addsub-inseltpoison.ll
  llvm/test/Transforms/InstCombine/X86/x86-addsub.ll
  llvm/test/Transforms/InstCombine/X86/x86-avx2-inseltpoison.ll
  llvm/test/Transforms/InstCombine/X86/x86-avx2.ll
  llvm/test/Transforms/InstCombine/X86/x86-avx512-inseltpoison.ll
  llvm/test/Transforms/InstCombine/X86/x86-avx512.ll
  llvm/test/Transforms/InstCombine/X86/x86-muldq-inseltpoison.ll
  llvm/test/Transforms/InstCombine/X86/x86-muldq.ll
  llvm/test/Transforms/InstCombine/X86/x86-pack-inseltpoison.ll
  llvm/test/Transforms/InstCombine/X86/x86-pack.ll
  llvm/test/Transforms/InstCombine/X86/x86-pshufb-inseltpoison.ll
  llvm/test/Transforms/InstCombine/X86/x86-pshufb.ll
  llvm/test/Transforms/InstCombine/X86/x86-sse4a-inseltpoison.ll
  llvm/test/Transforms/InstCombine/X86/x86-sse4a.ll
  llvm/test/Transforms/InstCombine/X86/x86-vpermil-inseltpoison.ll
  llvm/test/Transforms/InstCombine/X86/x86-vpermil.ll
  llvm/test/Transforms/InstCombine/broadcast-inseltpoison.ll
  llvm/test/Transforms/InstCombine/broadcast.ll
  llvm/test/Transforms/InstCombine/bswap-inseltpoison.ll
  llvm/test/Transforms/InstCombine/bswap.ll
  llvm/test/Transforms/InstCombine/canonicalize-vector-insert.ll
  llvm/test/Transforms/InstCombine/extractelement-inseltpoison.ll
  llvm/test/Transforms/InstCombine/extractelement.ll
  llvm/test/Transforms/InstCombine/insert-const-shuf.ll
  llvm/test/Transforms/InstCombine/insert-extract-shuffle-inseltpoison.ll
  llvm/test/Transforms/InstCombine/insert-extract-shuffle.ll
  llvm/test/Transforms/InstCombine/masked_intrinsics-inseltpoison.ll
  llvm/test/Transforms/InstCombine/masked_intrinsics.ll
  llvm/test/Transforms/InstCombine/nsw-inseltpoison.ll
  llvm/test/Transforms/InstCombine/nsw.ll
  llvm/test/Transforms/InstCombine/reduction-shufflevector.ll
  llvm/test/Transforms/InstCombine/select-extractelement-inseltpoison.ll
  llvm/test/Transforms/InstCombine/select-extractelement.ll
  llvm/test/Transforms/InstCombine/select-select.ll
  llvm/test/Transforms/InstCombine/shuffle-select-narrow-inseltpoison.ll
  llvm/test/Transforms/InstCombine/shuffle-select-narrow.ll
  llvm/test/Transforms/InstCombine/shuffle_select-inseltpoison.ll
  llvm/test/Transforms/InstCombine/shuffle_select.ll
  llvm/test/Transforms/InstCombine/shufflevec-bitcast-inseltpoison.ll
  llvm/test/Transforms/InstCombine/shufflevec-bitcast.ll
  llvm/test/Transforms/InstCombine/shufflevector-div-rem-inseltpoison.ll
  llvm/test/Transforms/InstCombine/shufflevector-div-rem.ll
  llvm/test/Transforms/InstCombine/sub-of-negatible-inseltpoison.ll
  llvm/test/Transforms/InstCombine/sub-of-negatible.ll
  llvm/test/Transform

[PATCH] D103874: [IR] Rename the shufflevector's undef mask to poison

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune updated this revision to Diff 375095.
aqjune added a comment.

Resurrect mistakenly removed test statements


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103874/new/

https://reviews.llvm.org/D103874

Files:
  clang/test/CodeGen/X86/avx-builtins.c
  clang/test/CodeGen/X86/avx512f-builtins.c
  clang/test/CodeGen/builtins-ppc-p10vector.c
  clang/test/CodeGen/builtins-ppc-p9vector.c
  clang/test/CodeGen/builtinshufflevector2.c
  clang/test/CodeGen/ext-vector.c
  clang/test/CodeGenOpenCL/as_type.cl
  clang/test/CodeGenOpenCL/partial_initializer.cl
  clang/test/CodeGenOpenCL/preserve_vec3.cl
  clang/test/CodeGenOpenCL/vector_literals.cl
  clang/test/CodeGenOpenCL/vector_shufflevector.cl
  llvm/include/llvm-c/Core.h
  llvm/include/llvm/IR/Instructions.h
  llvm/lib/Analysis/InstructionSimplify.cpp
  llvm/lib/Analysis/ValueTracking.cpp
  llvm/lib/IR/AsmWriter.cpp
  llvm/lib/IR/ConstantFold.cpp
  llvm/lib/IR/Core.cpp
  llvm/lib/IR/Instructions.cpp
  llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp
  llvm/lib/Transforms/InstCombine/InstCombineSelect.cpp
  llvm/lib/Transforms/InstCombine/InstCombineSimplifyDemanded.cpp
  llvm/lib/Transforms/InstCombine/InstCombineVectorOps.cpp
  llvm/lib/Transforms/InstCombine/InstructionCombining.cpp
  llvm/lib/Transforms/Scalar/ScalarizeMaskedMemIntrin.cpp
  llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
  llvm/lib/Transforms/Vectorize/VectorCombine.cpp
  llvm/test/Analysis/CostModel/AMDGPU/shufflevector.ll
  llvm/test/Analysis/CostModel/X86/reduction.ll
  llvm/test/Analysis/CostModel/X86/shuffle-extract_subvector.ll
  llvm/test/Analysis/CostModel/X86/shuffle-insert_subvector.ll
  llvm/test/Analysis/CostModel/X86/shuffle-single-src.ll
  llvm/test/CodeGen/AMDGPU/rewrite-out-arguments.ll
  llvm/test/CodeGen/Generic/expand-experimental-reductions.ll
  llvm/test/CodeGen/PowerPC/arg_promotion.ll
  llvm/test/Transforms/CodeGenPrepare/X86/x86-shuffle-sink-inseltpoison.ll
  llvm/test/Transforms/CodeGenPrepare/X86/x86-shuffle-sink.ll
  llvm/test/Transforms/DeadStoreElimination/masked-dead-store-inseltpoison.ll
  llvm/test/Transforms/DeadStoreElimination/masked-dead-store.ll
  
llvm/test/Transforms/InstCombine/AMDGPU/amdgcn-demanded-vector-elts-inseltpoison.ll
  llvm/test/Transforms/InstCombine/AMDGPU/amdgcn-demanded-vector-elts.ll
  llvm/test/Transforms/InstCombine/X86/x86-addsub-inseltpoison.ll
  llvm/test/Transforms/InstCombine/X86/x86-addsub.ll
  llvm/test/Transforms/InstCombine/X86/x86-avx2-inseltpoison.ll
  llvm/test/Transforms/InstCombine/X86/x86-avx2.ll
  llvm/test/Transforms/InstCombine/X86/x86-avx512-inseltpoison.ll
  llvm/test/Transforms/InstCombine/X86/x86-avx512.ll
  llvm/test/Transforms/InstCombine/X86/x86-muldq-inseltpoison.ll
  llvm/test/Transforms/InstCombine/X86/x86-muldq.ll
  llvm/test/Transforms/InstCombine/X86/x86-pack-inseltpoison.ll
  llvm/test/Transforms/InstCombine/X86/x86-pack.ll
  llvm/test/Transforms/InstCombine/X86/x86-pshufb-inseltpoison.ll
  llvm/test/Transforms/InstCombine/X86/x86-pshufb.ll
  llvm/test/Transforms/InstCombine/X86/x86-sse4a-inseltpoison.ll
  llvm/test/Transforms/InstCombine/X86/x86-sse4a.ll
  llvm/test/Transforms/InstCombine/X86/x86-vpermil-inseltpoison.ll
  llvm/test/Transforms/InstCombine/X86/x86-vpermil.ll
  llvm/test/Transforms/InstCombine/broadcast-inseltpoison.ll
  llvm/test/Transforms/InstCombine/broadcast.ll
  llvm/test/Transforms/InstCombine/bswap-inseltpoison.ll
  llvm/test/Transforms/InstCombine/bswap.ll
  llvm/test/Transforms/InstCombine/canonicalize-vector-insert.ll
  llvm/test/Transforms/InstCombine/extractelement-inseltpoison.ll
  llvm/test/Transforms/InstCombine/extractelement.ll
  llvm/test/Transforms/InstCombine/insert-const-shuf.ll
  llvm/test/Transforms/InstCombine/insert-extract-shuffle-inseltpoison.ll
  llvm/test/Transforms/InstCombine/insert-extract-shuffle.ll
  llvm/test/Transforms/InstCombine/masked_intrinsics-inseltpoison.ll
  llvm/test/Transforms/InstCombine/masked_intrinsics.ll
  llvm/test/Transforms/InstCombine/nsw-inseltpoison.ll
  llvm/test/Transforms/InstCombine/nsw.ll
  llvm/test/Transforms/InstCombine/reduction-shufflevector.ll
  llvm/test/Transforms/InstCombine/select-extractelement-inseltpoison.ll
  llvm/test/Transforms/InstCombine/select-extractelement.ll
  llvm/test/Transforms/InstCombine/select-select.ll
  llvm/test/Transforms/InstCombine/shuffle-select-narrow-inseltpoison.ll
  llvm/test/Transforms/InstCombine/shuffle-select-narrow.ll
  llvm/test/Transforms/InstCombine/shuffle_select-inseltpoison.ll
  llvm/test/Transforms/InstCombine/shuffle_select.ll
  llvm/test/Transforms/InstCombine/shufflevec-bitcast-inseltpoison.ll
  llvm/test/Transforms/InstCombine/shufflevec-bitcast.ll
  llvm/test/Transforms/InstCombine/shufflevector-div-rem-inseltpoison.ll
  llvm/test/Transforms/InstCombine/shufflevector-div-rem.ll
  llvm/test/Transforms/InstCombine/sub-of-negatible-inseltpoison.ll
  llvm/test/Transforms/InstCombine/sub-of-negatible.ll
  llvm/test/Transfor

[PATCH] D103874: [IR] Rename the shufflevector's undef mask to poison

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune marked an inline comment as done.
aqjune added inline comments.



Comment at: clang/test/CodeGen/X86/avx-builtins.c:182
   // CHECK-LABEL: test_mm256_castsi128_si256
-  // CHECK: shufflevector <2 x i64> %{{.*}}, <2 x i64> %{{.*}}, <4 x i32> 
+  // CHECK: shufflevector <2 x i64> %{{.*}}, <2 x i64> %{{.*}}, <4 x i32> 
   return _mm256_castsi128_si256(A);

RKSimon wrote:
> efriedma wrote:
> > This change might be visible to user code.
> Yes the length changing casts are worrying me as well - we could update the 
> header to insert zero into the upper elements I suppose, in many cases these 
> would be folded away by AVX ops implicitly zeroing the 128-bits. But we'd 
> definitely have the potential for regressions.
I quickly skimmed through the headers in clang/lib/Headers and listed the 
functions calling `__builtin_shufflevector` with at least one -1 mask operand.
It seems there aren't very many, which is good news; I found 17 functions only 
({F19257445}).

But, correctly fixing these headers seems to require a lot of work.
Since using the zero vector can cause performance regressions, we need to use a 
frozen poison (undef) vector to encode a vector having unspecified bits.
A few months ago, I created D104790 to start using freeze(vector poison) for 
`mm*_undefined*` intrinsics. However, teaching the existing codebase to 
successfully deal with the frozen poison vector was a pretty tough job.
When it comes to fixing the headers, there is even no C intrinsic function that 
represents a frozen poison vector AFAIK.

I'll appreciate any idea or help in addressing this issue. :/


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103874/new/

https://reviews.llvm.org/D103874

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D81678: Introduce noundef attribute at call sites for stricter poison analysis

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

I'm fine with any direction that helps people land test updates/implementations.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81678/new/

https://reviews.llvm.org/D81678

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D103874: [IR] Rename the shufflevector's undef mask to poison

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune created this revision.
aqjune added reviewers: nikic, efriedma, spatel, fhahn, lebedev.ri, RKSimon.
Herald added a reviewer: deadalnix.
Herald added subscribers: dexonsmith, kerbowa, pengfei, dmgreen, zzheng, 
kbarton, hiraditya, nhaehnle, jvesely, nemanjai.
aqjune requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

This is a patch that renames shufflevector's undef mask to poison.

By D93818 , shufflevector's undef mask isn't 
undef anymore; it returns poison instead.

  %v = shufflevector <2 x i8> %x, <2 x i8> %y, <2 x i8> 
  ; %v[0] = %x[0]
  ; %v[1] = poison

Since poison is more undefined than undef, this validates many existing 
transformations that we wanted to support.
Also, this allows more aggressive optimizations because poison is more 
propagative (e.g. poison & 0 = poison whereas undef & 0 != undef).

This patch updates shufflevector mask's printed string to be `poison` to match 
its new semantics.

This has changes in clang tests as well.
They are mainly about vector intrinsics being lowered into `shufflevector`.
The unused elements were filled with `undef` previously, but with this patch 
they are filled with `poison`.
Since they are unused elements anyway, I believe this isn't a functional change 
in fact.
But, I'm happy with this being double-checked by someone who works on these 
intrinsics as well.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D103874

Files:
  clang/test/CodeGen/X86/avx-builtins.c
  clang/test/CodeGen/X86/avx512f-builtins.c
  clang/test/CodeGen/aarch64-bf16-lane-intrinsics.c
  clang/test/CodeGen/builtins-ppc-p10vector.c
  clang/test/CodeGen/builtins-ppc-p9vector.c
  clang/test/CodeGen/builtinshufflevector2.c
  clang/test/CodeGen/ext-vector.c
  clang/test/CodeGenOpenCL/as_type.cl
  clang/test/CodeGenOpenCL/partial_initializer.cl
  clang/test/CodeGenOpenCL/preserve_vec3.cl
  clang/test/CodeGenOpenCL/vector_literals.cl
  clang/test/CodeGenOpenCL/vector_shufflevector.cl
  llvm/include/llvm-c/Core.h
  llvm/include/llvm/IR/Instructions.h
  llvm/lib/Analysis/InstructionSimplify.cpp
  llvm/lib/Analysis/ValueTracking.cpp
  llvm/lib/IR/AsmWriter.cpp
  llvm/lib/IR/ConstantFold.cpp
  llvm/lib/IR/Core.cpp
  llvm/lib/IR/Instructions.cpp
  llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp
  llvm/lib/Transforms/InstCombine/InstCombineSelect.cpp
  llvm/lib/Transforms/InstCombine/InstCombineSimplifyDemanded.cpp
  llvm/lib/Transforms/InstCombine/InstCombineVectorOps.cpp
  llvm/lib/Transforms/InstCombine/InstructionCombining.cpp
  llvm/lib/Transforms/Scalar/ScalarizeMaskedMemIntrin.cpp
  llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
  llvm/lib/Transforms/Vectorize/VectorCombine.cpp
  llvm/test/Analysis/CostModel/AMDGPU/shufflevector.ll
  llvm/test/Analysis/CostModel/X86/reduction.ll
  llvm/test/Analysis/CostModel/X86/shuffle-extract_subvector.ll
  llvm/test/Analysis/CostModel/X86/shuffle-insert_subvector.ll
  llvm/test/Analysis/CostModel/X86/shuffle-single-src.ll
  llvm/test/CodeGen/AMDGPU/rewrite-out-arguments.ll
  llvm/test/CodeGen/Generic/expand-experimental-reductions.ll
  llvm/test/CodeGen/PowerPC/arg_promotion.ll
  llvm/test/Transforms/CodeGenPrepare/X86/x86-shuffle-sink-inseltpoison.ll
  llvm/test/Transforms/CodeGenPrepare/X86/x86-shuffle-sink.ll
  llvm/test/Transforms/DeadStoreElimination/masked-dead-store-inseltpoison.ll
  llvm/test/Transforms/DeadStoreElimination/masked-dead-store.ll
  
llvm/test/Transforms/InstCombine/AMDGPU/amdgcn-demanded-vector-elts-inseltpoison.ll
  llvm/test/Transforms/InstCombine/AMDGPU/amdgcn-demanded-vector-elts.ll
  llvm/test/Transforms/InstCombine/X86/x86-addsub-inseltpoison.ll
  llvm/test/Transforms/InstCombine/X86/x86-addsub.ll
  llvm/test/Transforms/InstCombine/X86/x86-avx2-inseltpoison.ll
  llvm/test/Transforms/InstCombine/X86/x86-avx2.ll
  llvm/test/Transforms/InstCombine/X86/x86-avx512-inseltpoison.ll
  llvm/test/Transforms/InstCombine/X86/x86-avx512.ll
  llvm/test/Transforms/InstCombine/X86/x86-muldq-inseltpoison.ll
  llvm/test/Transforms/InstCombine/X86/x86-muldq.ll
  llvm/test/Transforms/InstCombine/X86/x86-pack-inseltpoison.ll
  llvm/test/Transforms/InstCombine/X86/x86-pack.ll
  llvm/test/Transforms/InstCombine/X86/x86-pshufb-inseltpoison.ll
  llvm/test/Transforms/InstCombine/X86/x86-pshufb.ll
  llvm/test/Transforms/InstCombine/X86/x86-sse4a-inseltpoison.ll
  llvm/test/Transforms/InstCombine/X86/x86-sse4a.ll
  llvm/test/Transforms/InstCombine/X86/x86-vpermil-inseltpoison.ll
  llvm/test/Transforms/InstCombine/X86/x86-vpermil.ll
  llvm/test/Transforms/InstCombine/broadcast-inseltpoison.ll
  llvm/test/Transforms/InstCombine/broadcast.ll
  llvm/test/Transforms/InstCombine/bswap-inseltpoison.ll
  llvm/test/Transforms/InstCombine/bswap.ll
  llvm/test/Transforms/InstCombine/canonicalize-vector-insert.ll
  llvm/test/Transforms/InstCombine/extractelement-inseltpoison.ll
  llvm/test/Transforms/InstCombine/extractelem

[PATCH] D103874: [IR] Rename the shufflevector's undef mask to poison

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

In D103874#2806519 , @efriedma wrote:

> I noted the cases where it looks like the undef->poison change might actually 
> impact code using compiler intrinsic functions that have external 
> specifications.  The relevant specifications say the elements in question are 
> "undefined", without really specifying what that means.
>
> Currently, for the Intel intrinsics, we treat "undefined" as something more 
> conservative than LLVM undef; see 
> https://github.com/llvm/llvm-project/blob/d2012d965d60c3258b3a69d024491698f8aec386/clang/lib/CodeGen/CGBuiltin.cpp#L12483
>  .  Maybe we should make the cast intrinsics more conservative to match.  And 
> maybe we should do the same for OpenCL.  Would need to do some backend work 
> to make sure we don't regress the generated code, though.

Makes sense, the PR (https://llvm.org/PR32176) that is left at the comment says 
it should be something like `freeze poison` as well. (BTW, this means the 
current shufflevector lowering is already incorrect as well..)

Then, _mm256_castsi128_si256 should be lowered into something like this:

  %fr = freeze <2 x i64> poison
  shufflevector <2 x i64> %x, <2 x i64> %fr, <4 x i32> 

BTW, the Intel intrinsic guide for _mm256_castsi128_si256 ( 
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm256_castsi128_si256&expand=628
 ) says:

  This intrinsic is only used for compilation and does not generate any 
instructions, thus it has zero latency.

We should teach the backend to understand the shufflevector+freeze form and 
lower it into an efficient assembly.

But, in practice, the frozen element won't be used in most of the cases; the 
middle-end's demanded elements analysis will trigger instcombine to almost 
always remove the freeze.
What do you think? If people agree, I'll create a separate patch that lowers 
this to the new freeze+shufflevector format (since it is already incorrect).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103874/new/

https://reviews.llvm.org/D103874

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D104790: [x86] fix mm*_undefined* intrinsics to use arbitrary frozen bit pattern

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune created this revision.
aqjune added reviewers: efriedma, spatel, craig.topper, RKSimon.
Herald added a subscriber: pengfei.
aqjune requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This fixes lowering of `mm*_undefined*` intrinsics to use `freeze poison` 
instead of zeroinitializer.
(mentioned & discussed in D103874 )


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D104790

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/X86/avx-builtins.c
  clang/test/CodeGen/X86/avx2-builtins.c
  clang/test/CodeGen/X86/avx512f-builtins.c
  clang/test/CodeGen/X86/sse-builtins.c
  clang/test/CodeGen/X86/sse2-builtins.c

Index: clang/test/CodeGen/X86/sse2-builtins.c
===
--- clang/test/CodeGen/X86/sse2-builtins.c
+++ clang/test/CodeGen/X86/sse2-builtins.c
@@ -1630,13 +1630,16 @@
 
 __m128d test_mm_undefined_pd() {
   // CHECK-LABEL: test_mm_undefined_pd
-  // CHECK: ret <2 x double> zeroinitializer
+  // CHECK: %[[FR:.*]] = freeze <2 x double> poison
+  // CHECK: ret <2 x double> %[[FR]]
   return _mm_undefined_pd();
 }
 
 __m128i test_mm_undefined_si128() {
   // CHECK-LABEL: test_mm_undefined_si128
-  // CHECK: ret <2 x i64> zeroinitializer
+  // CHECK: %[[FR:.*]] = freeze <2 x double> poison
+  // CHECK: %[[FR_BC:.*]] = bitcast <2 x double> %[[FR]] to <2 x i64>
+  // CHECK: ret <2 x i64> %[[FR_BC]]
   return _mm_undefined_si128();
 }
 
Index: clang/test/CodeGen/X86/sse-builtins.c
===
--- clang/test/CodeGen/X86/sse-builtins.c
+++ clang/test/CodeGen/X86/sse-builtins.c
@@ -786,7 +786,9 @@
 
 __m128 test_mm_undefined_ps() {
   // CHECK-LABEL: test_mm_undefined_ps
-  // CHECK: ret <4 x float> zeroinitializer
+  // CHECK: %[[FR:.*]] = freeze <2 x double> poison
+  // CHECK: %[[FR_BC:.*]] = bitcast <2 x double> %[[FR]] to <4 x float>
+  // CHECK: ret <4 x float> %[[FR_BC]]
   return _mm_undefined_ps();
 }
 
Index: clang/test/CodeGen/X86/avx512f-builtins.c
===
--- clang/test/CodeGen/X86/avx512f-builtins.c
+++ clang/test/CodeGen/X86/avx512f-builtins.c
@@ -3780,25 +3780,32 @@
 
 __m512 test_mm512_undefined() {
   // CHECK-LABEL: @test_mm512_undefined
-  // CHECK: ret <16 x float> zeroinitializer
+  // CHECK: %[[FR:.*]] = freeze <8 x double> poison
+  // CHECK: %[[FR_BC:.*]] = bitcast <8 x double> %[[FR]] to <16 x float>
+  // CHECK: ret <16 x float> %[[FR_BC]]
   return _mm512_undefined();
 }
 
 __m512 test_mm512_undefined_ps() {
   // CHECK-LABEL: @test_mm512_undefined_ps
-  // CHECK: ret <16 x float> zeroinitializer
+  // CHECK: %[[FR:.*]] = freeze <8 x double> poison
+  // CHECK: %[[FR_BC:.*]] = bitcast <8 x double> %[[FR]] to <16 x float>
+  // CHECK: ret <16 x float> %[[FR_BC]]
   return _mm512_undefined_ps();
 }
 
 __m512d test_mm512_undefined_pd() {
   // CHECK-LABEL: @test_mm512_undefined_pd
-  // CHECK: ret <8 x double> zeroinitializer
+  // CHECK: %[[FR:.*]] = freeze <8 x double> poison
+  // CHECK: ret <8 x double> %[[FR]]
   return _mm512_undefined_pd();
 }
 
 __m512i test_mm512_undefined_epi32() {
   // CHECK-LABEL: @test_mm512_undefined_epi32
-  // CHECK: ret <8 x i64> zeroinitializer
+  // CHECK: %[[FR:.*]] = freeze <8 x double> poison
+  // CHECK: %[[FR_BC:.*]] = bitcast <8 x double> %[[FR]] to <8 x i64>
+  // CHECK: ret <8 x i64> %[[FR_BC]]
   return _mm512_undefined_epi32();
 }
 
Index: clang/test/CodeGen/X86/avx2-builtins.c
===
--- clang/test/CodeGen/X86/avx2-builtins.c
+++ clang/test/CodeGen/X86/avx2-builtins.c
@@ -455,7 +455,9 @@
 
 __m128i test_mm_i32gather_epi64(long long const *b, __m128i c) {
   // CHECK-LABEL: test_mm_i32gather_epi64
-  // CHECK: call <2 x i64> @llvm.x86.avx2.gather.d.q(<2 x i64> zeroinitializer, i8* %{{.*}}, <4 x i32> %{{.*}}, <2 x i64> %{{.*}}, i8 2)
+  // CHECK: %[[FR:.*]] = freeze <2 x double> poison
+  // CHECK: %[[FR_BC:.*]] = bitcast <2 x double> %[[FR]] to <2 x i64>
+  // CHECK: call <2 x i64> @llvm.x86.avx2.gather.d.q(<2 x i64> %[[FR_BC]], i8* %{{.*}}, <4 x i32> %{{.*}}, <2 x i64> %{{.*}}, i8 2)
   return _mm_i32gather_epi64(b, c, 2);
 }
 
@@ -467,7 +469,9 @@
 
 __m256i test_mm256_i32gather_epi64(long long const *b, __m128i c) {
   // CHECK-LABEL: test_mm256_i32gather_epi64
-  // CHECK: call <4 x i64> @llvm.x86.avx2.gather.d.q.256(<4 x i64> zeroinitializer, i8* %{{.*}}, <4 x i32> %{{.*}}, <4 x i64> %{{.*}}, i8 2)
+  // CHECK: %[[FR:.*]] = freeze <4 x double> poison
+  // CHECK: %[[FR_BC:.*]] = bitcast <4 x double> %[[FR]] to <4 x i64>
+  // CHECK: call <4 x i64> @llvm.x86.avx2.gather.d.q.256(<4 x i64> %[[FR_BC]], i8* %{{.*}}, <4 x i32> %{{.*}}, <4 x i64> %{{.*}}, i8 2)
   return _mm256_i32gather_epi64(b, c, 2);
 }
 
@@ -479,10 +483,11 @@
 
 __m128d test_mm_i32gather_pd(double const *b, __m128i c) {
   

[PATCH] D104790: [x86] fix mm*_undefined* intrinsics to use arbitrary frozen bit pattern

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

I couldn't find end-to-end tests for checking assembly generation.
To check whether this is working ok, which tests should I write and how would 
it look like?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D104790/new/

https://reviews.llvm.org/D104790

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D104790: [x86] fix mm*_undefined* intrinsics to use arbitrary frozen bit pattern

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune updated this revision to Diff 354675.
aqjune added a comment.
Herald added subscribers: llvm-commits, ecnelises, hiraditya.
Herald added a project: LLVM.

- Update llvm's fast-isels tests for undefined intrinsics to compile 
freeze(poison)
- Update X86ISelLowering's getAVX2GatherNode and getGatherNode to consider 
freeze(poison) as well
- Update DAGCombiner to fold bitcast(freeze(poison)) -> freeze(poison)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D104790/new/

https://reviews.llvm.org/D104790

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/X86/avx-builtins.c
  clang/test/CodeGen/X86/avx2-builtins.c
  clang/test/CodeGen/X86/avx512f-builtins.c
  clang/test/CodeGen/X86/sse-builtins.c
  clang/test/CodeGen/X86/sse2-builtins.c
  llvm/include/llvm/CodeGen/SelectionDAGNodes.h
  llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
  llvm/lib/Target/X86/X86ISelLowering.cpp
  llvm/test/CodeGen/X86/avx-intrinsics-fast-isel.ll
  llvm/test/CodeGen/X86/sse2-intrinsics-fast-isel.ll

Index: llvm/test/CodeGen/X86/sse2-intrinsics-fast-isel.ll
===
--- llvm/test/CodeGen/X86/sse2-intrinsics-fast-isel.ll
+++ llvm/test/CodeGen/X86/sse2-intrinsics-fast-isel.ll
@@ -6386,18 +6386,30 @@
 }
 declare i32 @llvm.x86.sse2.ucomineq.sd(<2 x double>, <2 x double>) nounwind readnone
 
+define <4 x float> @test_mm_undefined_ps() {
+; CHECK-LABEL: test_mm_undefined_ps:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:ret{{[l|q]}} # encoding: [0xc3]
+  %v = freeze <2 x double> poison
+  %w = bitcast <2 x double> %v to <4 x float>
+  ret <4 x float> %w
+}
+
 define <2 x double> @test_mm_undefined_pd() {
 ; CHECK-LABEL: test_mm_undefined_pd:
 ; CHECK:   # %bb.0:
 ; CHECK-NEXT:ret{{[l|q]}} # encoding: [0xc3]
-  ret <2 x double> undef
+  %v = freeze <2 x double> poison
+  ret <2 x double> %v
 }
 
 define <2 x i64> @test_mm_undefined_si128() {
 ; CHECK-LABEL: test_mm_undefined_si128:
 ; CHECK:   # %bb.0:
 ; CHECK-NEXT:ret{{[l|q]}} # encoding: [0xc3]
-  ret <2 x i64> undef
+  %v = freeze <2 x double> poison
+  %w = bitcast <2 x double> %v to <2 x i64>
+  ret <2 x i64> %w
 }
 
 define <2 x i64> @test_mm_unpackhi_epi8(<2 x i64> %a0, <2 x i64> %a1) {
Index: llvm/test/CodeGen/X86/avx-intrinsics-fast-isel.ll
===
--- llvm/test/CodeGen/X86/avx-intrinsics-fast-isel.ll
+++ llvm/test/CodeGen/X86/avx-intrinsics-fast-isel.ll
@@ -2965,32 +2965,55 @@
 }
 declare i32 @llvm.x86.avx.ptestz.256(<4 x i64>, <4 x i64>) nounwind readnone
 
-define <2 x double> @test_mm_undefined_pd() nounwind {
-; CHECK-LABEL: test_mm_undefined_pd:
-; CHECK:   # %bb.0:
-; CHECK-NEXT:ret{{[l|q]}}
-  ret <2 x double> undef
-}
-
 define <4 x double> @test_mm256_undefined_pd() nounwind {
 ; CHECK-LABEL: test_mm256_undefined_pd:
 ; CHECK:   # %bb.0:
 ; CHECK-NEXT:ret{{[l|q]}}
-  ret <4 x double> undef
+  %v = freeze <4 x double> poison
+  ret <4 x double> %v
 }
 
 define <8 x float> @test_mm256_undefined_ps() nounwind {
 ; CHECK-LABEL: test_mm256_undefined_ps:
 ; CHECK:   # %bb.0:
 ; CHECK-NEXT:ret{{[l|q]}}
-  ret <8 x float> undef
+  %v = freeze <4 x double> poison
+  %w = bitcast <4 x double> %v to <8 x float>
+  ret <8 x float> %w
 }
 
 define <4 x i64> @test_mm256_undefined_si256() nounwind {
 ; CHECK-LABEL: test_mm256_undefined_si256:
 ; CHECK:   # %bb.0:
 ; CHECK-NEXT:ret{{[l|q]}}
-  ret <4 x i64> undef
+  %v = freeze <4 x double> poison
+  %w = bitcast <4 x double> %v to <4 x i64>
+  ret <4 x i64> %w
+}
+
+define <16 x float> @test_mm512_undefined() nounwind {
+; CHECK-LABEL: test_mm512_undefined:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:ret{{[l|q]}}
+  %v = freeze <8 x double> poison
+  %w = bitcast <8 x double> %v to <16 x float>
+  ret <16 x float> %w
+}
+
+define <8 x double> @test_mm512_undefined_pd() nounwind {
+; CHECK-LABEL: test_mm512_undefined_pd:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:ret{{[l|q]}}
+  %v = freeze <8 x double> poison
+  ret <8 x double> %v
+}
+
+define <8 x i64> @test_mm512_undefined_epi32() nounwind {
+; CHECK-LABEL: test_mm512_undefined_epi32:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:ret{{[l|q]}}
+  %v = freeze <8 x i64> poison
+  ret <8 x i64> %v
 }
 
 define <4 x double> @test_mm256_unpackhi_pd(<4 x double> %a0, <4 x double> %a1) nounwind {
Index: llvm/lib/Target/X86/X86ISelLowering.cpp
===
--- llvm/lib/Target/X86/X86ISelLowering.cpp
+++ llvm/lib/Target/X86/X86ISelLowering.cpp
@@ -26011,10 +26011,11 @@
 TLI.getPointerTy(DAG.getDataLayout()));
   EVT MaskVT = Mask.getValueType().changeVectorElementTypeToInteger();
   SDVTList VTs = DAG.getVTList(Op.getValueType(), MVT::Other);
-  // If source is undef or we know it won't be used, use a zero vector
-  // to break register dependency.
+  // If source is undef or its f

[PATCH] D104790: [x86] fix mm*_undefined* intrinsics to use arbitrary frozen bit pattern

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune updated this revision to Diff 354678.
aqjune added a comment.

Minor fixes


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D104790/new/

https://reviews.llvm.org/D104790

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/X86/avx-builtins.c
  clang/test/CodeGen/X86/avx2-builtins.c
  clang/test/CodeGen/X86/avx512f-builtins.c
  clang/test/CodeGen/X86/sse-builtins.c
  clang/test/CodeGen/X86/sse2-builtins.c
  llvm/include/llvm/CodeGen/SelectionDAGNodes.h
  llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
  llvm/lib/Target/X86/X86ISelLowering.cpp
  llvm/test/CodeGen/X86/avx-intrinsics-fast-isel.ll
  llvm/test/CodeGen/X86/sse2-intrinsics-fast-isel.ll

Index: llvm/test/CodeGen/X86/sse2-intrinsics-fast-isel.ll
===
--- llvm/test/CodeGen/X86/sse2-intrinsics-fast-isel.ll
+++ llvm/test/CodeGen/X86/sse2-intrinsics-fast-isel.ll
@@ -6386,18 +6386,30 @@
 }
 declare i32 @llvm.x86.sse2.ucomineq.sd(<2 x double>, <2 x double>) nounwind readnone
 
+define <4 x float> @test_mm_undefined_ps() {
+; CHECK-LABEL: test_mm_undefined_ps:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:ret{{[l|q]}} # encoding: [0xc3]
+  %v = freeze <2 x double> poison
+  %w = bitcast <2 x double> %v to <4 x float>
+  ret <4 x float> %w
+}
+
 define <2 x double> @test_mm_undefined_pd() {
 ; CHECK-LABEL: test_mm_undefined_pd:
 ; CHECK:   # %bb.0:
 ; CHECK-NEXT:ret{{[l|q]}} # encoding: [0xc3]
-  ret <2 x double> undef
+  %v = freeze <2 x double> poison
+  ret <2 x double> %v
 }
 
 define <2 x i64> @test_mm_undefined_si128() {
 ; CHECK-LABEL: test_mm_undefined_si128:
 ; CHECK:   # %bb.0:
 ; CHECK-NEXT:ret{{[l|q]}} # encoding: [0xc3]
-  ret <2 x i64> undef
+  %v = freeze <2 x double> poison
+  %w = bitcast <2 x double> %v to <2 x i64>
+  ret <2 x i64> %w
 }
 
 define <2 x i64> @test_mm_unpackhi_epi8(<2 x i64> %a0, <2 x i64> %a1) {
Index: llvm/test/CodeGen/X86/avx-intrinsics-fast-isel.ll
===
--- llvm/test/CodeGen/X86/avx-intrinsics-fast-isel.ll
+++ llvm/test/CodeGen/X86/avx-intrinsics-fast-isel.ll
@@ -2965,32 +2965,55 @@
 }
 declare i32 @llvm.x86.avx.ptestz.256(<4 x i64>, <4 x i64>) nounwind readnone
 
-define <2 x double> @test_mm_undefined_pd() nounwind {
-; CHECK-LABEL: test_mm_undefined_pd:
-; CHECK:   # %bb.0:
-; CHECK-NEXT:ret{{[l|q]}}
-  ret <2 x double> undef
-}
-
 define <4 x double> @test_mm256_undefined_pd() nounwind {
 ; CHECK-LABEL: test_mm256_undefined_pd:
 ; CHECK:   # %bb.0:
 ; CHECK-NEXT:ret{{[l|q]}}
-  ret <4 x double> undef
+  %v = freeze <4 x double> poison
+  ret <4 x double> %v
 }
 
 define <8 x float> @test_mm256_undefined_ps() nounwind {
 ; CHECK-LABEL: test_mm256_undefined_ps:
 ; CHECK:   # %bb.0:
 ; CHECK-NEXT:ret{{[l|q]}}
-  ret <8 x float> undef
+  %v = freeze <4 x double> poison
+  %w = bitcast <4 x double> %v to <8 x float>
+  ret <8 x float> %w
 }
 
 define <4 x i64> @test_mm256_undefined_si256() nounwind {
 ; CHECK-LABEL: test_mm256_undefined_si256:
 ; CHECK:   # %bb.0:
 ; CHECK-NEXT:ret{{[l|q]}}
-  ret <4 x i64> undef
+  %v = freeze <4 x double> poison
+  %w = bitcast <4 x double> %v to <4 x i64>
+  ret <4 x i64> %w
+}
+
+define <16 x float> @test_mm512_undefined() nounwind {
+; CHECK-LABEL: test_mm512_undefined:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:ret{{[l|q]}}
+  %v = freeze <8 x double> poison
+  %w = bitcast <8 x double> %v to <16 x float>
+  ret <16 x float> %w
+}
+
+define <8 x double> @test_mm512_undefined_pd() nounwind {
+; CHECK-LABEL: test_mm512_undefined_pd:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:ret{{[l|q]}}
+  %v = freeze <8 x double> poison
+  ret <8 x double> %v
+}
+
+define <8 x i64> @test_mm512_undefined_epi32() nounwind {
+; CHECK-LABEL: test_mm512_undefined_epi32:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:ret{{[l|q]}}
+  %v = freeze <8 x i64> poison
+  ret <8 x i64> %v
 }
 
 define <4 x double> @test_mm256_unpackhi_pd(<4 x double> %a0, <4 x double> %a1) nounwind {
Index: llvm/lib/Target/X86/X86ISelLowering.cpp
===
--- llvm/lib/Target/X86/X86ISelLowering.cpp
+++ llvm/lib/Target/X86/X86ISelLowering.cpp
@@ -26011,10 +26011,11 @@
 TLI.getPointerTy(DAG.getDataLayout()));
   EVT MaskVT = Mask.getValueType().changeVectorElementTypeToInteger();
   SDVTList VTs = DAG.getVTList(Op.getValueType(), MVT::Other);
-  // If source is undef or we know it won't be used, use a zero vector
-  // to break register dependency.
+  // If source is undef, frozen undef with one use only, or we
+  // know it won't be used, use a zero vector to break register dependency.
   // TODO: use undef instead and let BreakFalseDeps deal with it?
-  if (Src.isUndef() || ISD::isBuildVectorAllOnes(Mask.getNode()))
+  if (Src.isUndef() || (Src.isFreezeUndef() && Src.hasOneUse()) ||
+  ISD::isBuildVector

[PATCH] D104790: [x86] fix mm*_undefined* intrinsics to use arbitrary frozen bit pattern

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune updated this revision to Diff 354682.
aqjune added a comment.

- Update llvm/test/CodeGen/X86/sse-intrinsics-fast-isel.ll as well


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D104790/new/

https://reviews.llvm.org/D104790

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/X86/avx-builtins.c
  clang/test/CodeGen/X86/avx2-builtins.c
  clang/test/CodeGen/X86/avx512f-builtins.c
  clang/test/CodeGen/X86/sse-builtins.c
  clang/test/CodeGen/X86/sse2-builtins.c
  llvm/include/llvm/CodeGen/SelectionDAGNodes.h
  llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
  llvm/lib/Target/X86/X86ISelLowering.cpp
  llvm/test/CodeGen/X86/avx-intrinsics-fast-isel.ll
  llvm/test/CodeGen/X86/sse-intrinsics-fast-isel.ll
  llvm/test/CodeGen/X86/sse2-intrinsics-fast-isel.ll

Index: llvm/test/CodeGen/X86/sse2-intrinsics-fast-isel.ll
===
--- llvm/test/CodeGen/X86/sse2-intrinsics-fast-isel.ll
+++ llvm/test/CodeGen/X86/sse2-intrinsics-fast-isel.ll
@@ -6390,14 +6390,17 @@
 ; CHECK-LABEL: test_mm_undefined_pd:
 ; CHECK:   # %bb.0:
 ; CHECK-NEXT:ret{{[l|q]}} # encoding: [0xc3]
-  ret <2 x double> undef
+  %v = freeze <2 x double> poison
+  ret <2 x double> %v
 }
 
 define <2 x i64> @test_mm_undefined_si128() {
 ; CHECK-LABEL: test_mm_undefined_si128:
 ; CHECK:   # %bb.0:
 ; CHECK-NEXT:ret{{[l|q]}} # encoding: [0xc3]
-  ret <2 x i64> undef
+  %v = freeze <2 x double> poison
+  %w = bitcast <2 x double> %v to <2 x i64>
+  ret <2 x i64> %w
 }
 
 define <2 x i64> @test_mm_unpackhi_epi8(<2 x i64> %a0, <2 x i64> %a1) {
Index: llvm/test/CodeGen/X86/sse-intrinsics-fast-isel.ll
===
--- llvm/test/CodeGen/X86/sse-intrinsics-fast-isel.ll
+++ llvm/test/CodeGen/X86/sse-intrinsics-fast-isel.ll
@@ -3513,7 +3513,9 @@
 ; CHECK-LABEL: test_mm_undefined_ps:
 ; CHECK:   # %bb.0:
 ; CHECK-NEXT:ret{{[l|q]}} # encoding: [0xc3]
-  ret <4 x float> undef
+  %v = freeze <2 x double> poison
+  %w = bitcast <2 x double> %v to <4 x float>
+  ret <4 x float> %w
 }
 
 define <4 x float> @test_mm_unpackhi_ps(<4 x float> %a0, <4 x float> %a1) nounwind {
Index: llvm/test/CodeGen/X86/avx-intrinsics-fast-isel.ll
===
--- llvm/test/CodeGen/X86/avx-intrinsics-fast-isel.ll
+++ llvm/test/CodeGen/X86/avx-intrinsics-fast-isel.ll
@@ -2965,32 +2965,55 @@
 }
 declare i32 @llvm.x86.avx.ptestz.256(<4 x i64>, <4 x i64>) nounwind readnone
 
-define <2 x double> @test_mm_undefined_pd() nounwind {
-; CHECK-LABEL: test_mm_undefined_pd:
-; CHECK:   # %bb.0:
-; CHECK-NEXT:ret{{[l|q]}}
-  ret <2 x double> undef
-}
-
 define <4 x double> @test_mm256_undefined_pd() nounwind {
 ; CHECK-LABEL: test_mm256_undefined_pd:
 ; CHECK:   # %bb.0:
 ; CHECK-NEXT:ret{{[l|q]}}
-  ret <4 x double> undef
+  %v = freeze <4 x double> poison
+  ret <4 x double> %v
 }
 
 define <8 x float> @test_mm256_undefined_ps() nounwind {
 ; CHECK-LABEL: test_mm256_undefined_ps:
 ; CHECK:   # %bb.0:
 ; CHECK-NEXT:ret{{[l|q]}}
-  ret <8 x float> undef
+  %v = freeze <4 x double> poison
+  %w = bitcast <4 x double> %v to <8 x float>
+  ret <8 x float> %w
 }
 
 define <4 x i64> @test_mm256_undefined_si256() nounwind {
 ; CHECK-LABEL: test_mm256_undefined_si256:
 ; CHECK:   # %bb.0:
 ; CHECK-NEXT:ret{{[l|q]}}
-  ret <4 x i64> undef
+  %v = freeze <4 x double> poison
+  %w = bitcast <4 x double> %v to <4 x i64>
+  ret <4 x i64> %w
+}
+
+define <16 x float> @test_mm512_undefined() nounwind {
+; CHECK-LABEL: test_mm512_undefined:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:ret{{[l|q]}}
+  %v = freeze <8 x double> poison
+  %w = bitcast <8 x double> %v to <16 x float>
+  ret <16 x float> %w
+}
+
+define <8 x double> @test_mm512_undefined_pd() nounwind {
+; CHECK-LABEL: test_mm512_undefined_pd:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:ret{{[l|q]}}
+  %v = freeze <8 x double> poison
+  ret <8 x double> %v
+}
+
+define <8 x i64> @test_mm512_undefined_epi32() nounwind {
+; CHECK-LABEL: test_mm512_undefined_epi32:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:ret{{[l|q]}}
+  %v = freeze <8 x i64> poison
+  ret <8 x i64> %v
 }
 
 define <4 x double> @test_mm256_unpackhi_pd(<4 x double> %a0, <4 x double> %a1) nounwind {
Index: llvm/lib/Target/X86/X86ISelLowering.cpp
===
--- llvm/lib/Target/X86/X86ISelLowering.cpp
+++ llvm/lib/Target/X86/X86ISelLowering.cpp
@@ -26011,10 +26011,11 @@
 TLI.getPointerTy(DAG.getDataLayout()));
   EVT MaskVT = Mask.getValueType().changeVectorElementTypeToInteger();
   SDVTList VTs = DAG.getVTList(Op.getValueType(), MVT::Other);
-  // If source is undef or we know it won't be used, use a zero vector
-  // to break register dependency.
+  // If source is undef, frozen undef with one use only, or we
+  // know it w

[PATCH] D104790: [x86] fix mm*_undefined* intrinsics to use arbitrary frozen bit pattern

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

In D104790#2836463 , @craig.topper 
wrote:

> In D104790#2836253 , @aqjune wrote:
>
>> I couldn't find end-to-end tests for checking assembly generation.
>> To check whether this is working ok, which tests should I write and how 
>> would it look like?
>
> There are tests like test/CodeGen/X86/avx-intrinsics-fast-isel.ll that are 
> supposed to contain the IR the frontend generates. They mostly contain 
> optimized IR, but then run fast-isel in the backend. I don't think all 
> intrinsics are tested this way.

Thank you for the info. I updated three *-fast-isel.ll files to check this.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D104790/new/

https://reviews.llvm.org/D104790

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D104790: [x86] fix mm*_undefined* intrinsics to use arbitrary frozen bit pattern

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

In D104790#2842523 , @nikic wrote:

> Is this actually better in any meaningful way? InstCombine will turn `freeze 
> poison` into `zeroinitializer`, and until then this is just a completely 
> opaque value.

I think to correctly emit IR for intrinsics like mm256_castsi128_si256 (D103874 
 has more context) efficient handling of this 
kind of pattern is necessary:

  %v = freeze  poison
  %w = shufflevector %a, %v, mask

The zeroinitializer folding is done by InstCombine's visitFreeze, which should 
be fixed maybe.
I'll play with some patterns and create patches for this.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D104790/new/

https://reviews.llvm.org/D104790

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D82317: [Clang/Test]: Update tests where `noundef` attribute is necessary

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

I asked @hyeongyukim (who is a participant of google summer of code) to rebase 
this patch and make an updated version.
I thought it was a good goal for him to target, as the validity of the 
enable-noundef flag is already reviewed and the changes are syntactic updates 
to the existing tests.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D82317/new/

https://reviews.llvm.org/D82317

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D92270: [ConstantFold] Fold more operations to poison

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added inline comments.



Comment at: llvm/lib/IR/ConstantFold.cpp:633
 // the input constant.
-return UndefValue::get(DestTy);
+return PoisonValue::get(DestTy);
   }

neildhar wrote:
> spatel wrote:
> > MatzeB wrote:
> > > I believe this is causing some of our clients trouble, especially since 
> > > we somehow have a `-fno-strict-float-cast-overflow` flag in clang that 
> > > says float->int overflows are not UB... (CC @spatel )
> > I can guess at what the example looks like, but it would be great to have a 
> > reduced test.
> > There should be a function attribute in IR corresponding to that clang 
> > flag, so we could alter the behavior here based on checking that? Not sure 
> > if there's precedence for that kind of transform though.
> Here's a minimal repro for the issue we ran into: 
> https://godbolt.org/z/Wdr7q1a9M
Clang is lowering fp-to-int casts into fptosi/ui 
(https://godbolt.org/z/Gz3Y7YKKf), but I think in this case clang must emit the 
fptosi.sat intrinsic: 
https://llvm.org/docs/LangRef.html#llvm-fptosi-sat-intrinsic
It guarantees that the result is well-defined.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D92270/new/

https://reviews.llvm.org/D92270

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D105169: [Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and turn it off by default

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

I am not familiar with inline assembly, but it seems the output variable (`%0`) 
is not updated because it does not appear in the code.

  1382   __asm__ __volatile__(
  1383"mov x0,x2\n" /* flags  */
  1384"mov x2,x4\n" /* ptid  */
  1385"mov x3,x5\n" /* tls  */
  1386"mov x4,x6\n" /* ctid  */
  1387"mov x8,%9\n" /* clone  */
  1388 
  1389"svc 0x0\n"
  1390 
  1391/* if (%r0 != 0)
  1392 *   return %r0;
  1393 */
  1394"cmp x0, #0\n"
  1395"bne 1f\n"
  1396 
  1397/* In the child, now. Call "fn(arg)". */
  1398"ldp x1, x0, [sp], #16\n"
  1399"blr x1\n"
  1400 
  1401/* Call _exit(%r0).  */
  1402"mov x8, %10\n"
  1403"svc 0x0\n"
  1404  "1:\n"
  1405 
  1406: "=r" (res)
  1407: "i"(-EINVAL),
  1408  "r"(__fn), "r"(__stack), "r"(__flags), 
"r"(__arg),
  1409  "r"(__ptid), "r"(__tls), "r"(__ctid),
  1410  "i"(__NR_clone), "i"(__NR_exit)
  1411: "x30", "memory");

Should `%0` be updated?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105169/new/

https://reviews.llvm.org/D105169

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D105169: [Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and turn it off by default

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

In D105169#3104262 , @eugenis wrote:

> You are absolutely right. X86 variant uses an "=a" constraint (rax register), 
> others pin the output variable to a specific register with __asm__ 
> declaration. It appears we've missed it in Aarch64.
>
> Could you check if __asm__("x0") in the declaration of res helps?

Thank you, It worked!
Only a couple of failures in ASAN left, and we are investigating them.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105169/new/

https://reviews.llvm.org/D105169

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D136737: [Draft] [clang] Add builtin_unspecified_value

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune created this revision.
Herald added subscribers: steakhal, martong, arphaman.
Herald added a reviewer: shafik.
Herald added a reviewer: NoQ.
Herald added a project: All.
aqjune requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This patch adds a builtin constant that lowers to `freeze(poison)`.
This is necessary to patch the intrinsics like e.g., `mm256_castsi128_si256` to 
be lowered to the following sequence:

  %a1 = freeze <2 x double> poison // <- would like to represent this as 
'__builtin_unspecified_value' in C/C++.
  %res = shufflevector <2 x double> %a0, <2 x double> %a1, <4 x i32> 

Currently it is being lowered to:

  %res = shufflevector <2x  double> %a0, undef, <4 x i32> 

The current lowering may incorrectly introduce undefined behavior.

A related, previous patch was here: https://reviews.llvm.org/D130339


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D136737

Files:
  clang/include/clang-c/Index.h
  clang/include/clang/AST/Expr.h
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/include/clang/Basic/StmtNodes.td
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/Expr.cpp
  clang/lib/AST/ExprClassification.cpp
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/AST/StmtProfile.cpp
  clang/lib/Sema/SemaExceptionSpec.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReaderStmt.cpp
  clang/lib/Serialization/ASTWriterStmt.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
  clang/tools/libclang/CXCursor.cpp

Index: clang/tools/libclang/CXCursor.cpp
===
--- clang/tools/libclang/CXCursor.cpp
+++ clang/tools/libclang/CXCursor.cpp
@@ -475,6 +475,10 @@
 K = CXCursor_GNUNullExpr;
 break;
 
+  case Stmt::UnspecifiedValueExprClass:
+K = CXCursor_UnspecifiedValueExpr;
+break;
+
   case Stmt::CXXStaticCastExprClass:
 K = CXCursor_CXXStaticCastExpr;
 break;
Index: clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
===
--- clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
+++ clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
@@ -1889,6 +1889,7 @@
 case Stmt::ObjCSelectorExprClass:
 case Stmt::ParenListExprClass:
 case Stmt::ShuffleVectorExprClass:
+case Stmt::UnspecifiedValueExprClass:
 case Stmt::ConvertVectorExprClass:
 case Stmt::VAArgExprClass:
 case Stmt::CUDAKernelCallExprClass:
Index: clang/lib/Serialization/ASTWriterStmt.cpp
===
--- clang/lib/Serialization/ASTWriterStmt.cpp
+++ clang/lib/Serialization/ASTWriterStmt.cpp
@@ -1195,6 +1195,12 @@
   Code = serialization::EXPR_GNU_NULL;
 }
 
+void ASTStmtWriter::VisitUnspecifiedValueExpr(UnspecifiedValueExpr *E) {
+  VisitExpr(E);
+  Record.AddSourceLocation(E->getTokenLocation());
+  Code = serialization::EXPR_UNSPECIFIED_VALUE;
+}
+
 void ASTStmtWriter::VisitShuffleVectorExpr(ShuffleVectorExpr *E) {
   VisitExpr(E);
   Record.push_back(E->getNumSubExprs());
Index: clang/lib/Serialization/ASTReaderStmt.cpp
===
--- clang/lib/Serialization/ASTReaderStmt.cpp
+++ clang/lib/Serialization/ASTReaderStmt.cpp
@@ -1316,6 +1316,11 @@
   E->setTokenLocation(readSourceLocation());
 }
 
+void ASTStmtReader::VisitUnspecifiedValueExpr(UnspecifiedValueExpr *E) {
+  VisitExpr(E);
+  E->setTokenLocation(readSourceLocation());
+}
+
 void ASTStmtReader::VisitShuffleVectorExpr(ShuffleVectorExpr *E) {
   VisitExpr(E);
   SmallVector Exprs;
@@ -3077,6 +3082,10 @@
   S = new (Context) GNUNullExpr(Empty);
   break;
 
+case EXPR_UNSPECIFIED_VALUE:
+  S = new (Context) UnspecifiedValueExpr(Empty);
+  break;
+
 case EXPR_SHUFFLE_VECTOR:
   S = new (Context) ShuffleVectorExpr(Empty);
   break;
Index: clang/lib/Sema/TreeTransform.h
===
--- clang/lib/Sema/TreeTransform.h
+++ clang/lib/Sema/TreeTransform.h
@@ -11719,6 +11719,12 @@
   return E;
 }
 
+template
+ExprResult
+TreeTransform::TransformUnspecifiedValueExpr(UnspecifiedValueExpr *E) {
+  return E;
+}
+
 template
 ExprResult
 TreeTransform::TransformCXXOperatorCallExpr(CXXOperatorCallExpr *E) {
Index: clang/lib/Sema/SemaExceptionSpec.cpp
===
--- clang/lib/Sema/SemaExceptionSpec.cpp
+++ clang/lib/Sema/SemaExceptionSpec.cpp
@@ -1404,6 +1404,7 @@
   case Expr::SourceLocExprClass:
   case Expr::ConceptSpecializationExprClass:
   case Expr::RequiresExprClass:
+  case Expr::UnspecifiedValueExprClass:
 // These expressions can never throw.
 return CT_Cannot;
 
Index: clang/lib/AST/StmtProfile.cpp
===
--- clang/lib/AST/StmtProfile.cpp
+++ clang/lib/AST/StmtProfile.cpp
@@ -1472,6 +1472

[PATCH] D136737: [Draft] [clang] Add builtin_unspecified_value

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

The updates are analogous to how `GNUNullExprClass` is processed because 
`UnspecifiedValueExprClass` and it is similar (have no operand).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136737/new/

https://reviews.llvm.org/D136737

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D103874: [IR] Rename the shufflevector's undef mask to poison

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added inline comments.



Comment at: clang/test/CodeGen/X86/avx-builtins.c:182
   // CHECK-LABEL: test_mm256_castsi128_si256
-  // CHECK: shufflevector <2 x i64> %{{.*}}, <2 x i64> %{{.*}}, <4 x i32> 
+  // CHECK: shufflevector <2 x i64> %{{.*}}, <2 x i64> %{{.*}}, <4 x i32> 
   return _mm256_castsi128_si256(A);

aqjune wrote:
> RKSimon wrote:
> > efriedma wrote:
> > > This change might be visible to user code.
> > Yes the length changing casts are worrying me as well - we could update the 
> > header to insert zero into the upper elements I suppose, in many cases 
> > these would be folded away by AVX ops implicitly zeroing the 128-bits. But 
> > we'd definitely have the potential for regressions.
> I quickly skimmed through the headers in clang/lib/Headers and listed the 
> functions calling `__builtin_shufflevector` with at least one -1 mask operand.
> It seems there aren't very many, which is good news; I found 17 functions 
> only ({F19257445}).
> 
> But, correctly fixing these headers seems to require a lot of work.
> Since using the zero vector can cause performance regressions, we need to use 
> a frozen poison (undef) vector to encode a vector having unspecified bits.
> A few months ago, I created D104790 to start using freeze(vector poison) for 
> `mm*_undefined*` intrinsics. However, teaching the existing codebase to 
> successfully deal with the frozen poison vector was a pretty tough job.
> When it comes to fixing the headers, there is even no C intrinsic function 
> that represents a frozen poison vector AFAIK.
> 
> I'll appreciate any idea or help in addressing this issue. :/
Okay, D130339 has finally been merged.

I will make a patch that updates the `mm256_castsi128_si256` and its family 
functions to emit shufflevector with freeze(poison) operand.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103874/new/

https://reviews.llvm.org/D103874

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D103874: [IR] Rename the shufflevector's undef mask to poison

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.
Herald added subscribers: jsji, kosarev.
Herald added a project: All.

It seems llvm/lib/Target/X86/X86ISelLowering.cpp's LowerAVXCONCAT_VECTORS is 
relevant to efficient lowering of `shufflevector %x, freeze(poison), mask`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103874/new/

https://reviews.llvm.org/D103874

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D152658: [InstCombine] Change SimplifyDemandedVectorElts to use PoisonElts instead of UndefElts

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

Hi, thanks for your hard work!




Comment at: llvm/lib/Transforms/InstCombine/InstructionCombining.cpp:1653
-  if (ShMask[I] >= 0) {
-assert(ShMask[I] < (int)NumElts && "Not expecting narrowing shuffle");
 Constant *NewCElt = NewVecC[ShMask[I]];

This seems to be 



Comment at: llvm/test/Transforms/InstCombine/vec_shuffle.ll:373
+; CHECK-NEXT: [[T2:%.*]] = shufflevector <2 x i32> [[T1]], <2 x i32> undef, <1 
x i32> zeroinitializer
+; CHECK-NEXT:ret <1 x i32> [[T2]]
 ;

Do you have any idea about the reason of this regression? 



Comment at: llvm/test/Transforms/InstCombine/vector-casts-inseltpoison.ll:297
 ; CHECK-NEXT:[[TMP1:%.*]] = trunc i32 [[X:%.*]] to i16
-; CHECK-NEXT:[[TRUNC:%.*]] = insertelement <3 x i16> undef, i16 [[TMP1]], 
i64 1
+; CHECK-NEXT:[[TRUNC:%.*]] = insertelement <3 x i16> , i16 [[TMP1]], i64 1
 ; CHECK-NEXT:ret <3 x i16> [[TRUNC]]

This looks interesting - do you have idea how the undef elements are introduced?



Comment at: llvm/test/Transforms/SLPVectorizer/X86/alternate-int.ll:451
 ; AVX2-NEXT:[[TMP4:%.*]] = sdiv <2 x i32> [[TMP3]], 
-; AVX2-NEXT:[[R1:%.*]] = insertelement <8 x i32> , i32 [[AB1]], 
i64 1
+; AVX2-NEXT:[[R1:%.*]] = insertelement <8 x i32> , i32 
[[AB1]], i64 1
 ; AVX2-NEXT:[[TMP5:%.*]] = shufflevector <2 x i32> [[TMP2]], <2 x i32> 
poison, <8 x i32> 

Do you have any idea about why the 5'th element is undef, not poison?



Comment at: llvm/test/Transforms/SLPVectorizer/X86/pr49081.ll:11
+; CHECK-NEXT:[[TMP4:%.*]] = insertelement <4 x float> poison, float 
[[TMP3]], i64 0
+; CHECK-NEXT:[[TMP5:%.*]] = shufflevector <4 x float> [[TMP4]], <4 x 
float> poison, <4 x i32> 
 ; CHECK-NEXT:[[TMP6:%.*]] = shufflevector <4 x i32> [[TMP0]], <4 x i32> 
poison, <2 x i32> 

This change looks interesting, I think it is worth investigating why this 
happened.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D152658/new/

https://reviews.llvm.org/D152658

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D152658: [InstCombine] Change SimplifyDemandedVectorElts to use PoisonElts instead of UndefElts

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added inline comments.



Comment at: llvm/lib/Transforms/InstCombine/InstructionCombining.cpp:1653
-  if (ShMask[I] >= 0) {
-assert(ShMask[I] < (int)NumElts && "Not expecting narrowing shuffle");
 Constant *NewCElt = NewVecC[ShMask[I]];

aqjune wrote:
> This seems to be 
Nevermind, please ignore this comment.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D152658/new/

https://reviews.llvm.org/D152658

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D74935: [LangRef][AliasAnalysis] Clarify `noalias` affects only modified objects

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

Hi,
The term 'object' seems ambiguous to me. For example,

  void f(i32* noalias x, i32* noalias y) {
*x = 1;
*y = 2;
  }
  
  int x[2];
  f(&x[0], &x[1]);

If object means an allocation, this should be UB, because x and y are pointing 
to the same object.
Memory location seems clearer to me.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74935/new/

https://reviews.llvm.org/D74935



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D74935: [LangRef][AliasAnalysis] Clarify `noalias` affects only modified objects

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

Never mind, I see that the keyword object comes from the alias analysis 
document. The alias analysis document is using the term object consistently.
I was confused because the term is used at llvm.objectsize intrinsic's LangRef 
documentation, which seems to refer an allocation unit. gep inbounds text also 
used term 'allocated object', but I guess it is different from that.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74935/new/

https://reviews.llvm.org/D74935



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D74935: [LangRef][AliasAnalysis] Clarify `noalias` affects only modified objects

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

I agree readnone functions can read constant memory; at least LangRef doesn't 
restrict readnone functions from accessing memory (unless it changes a state 
visible to caller). I see that readnone is also attached to a function that 
loads from/stores to alloca: https://godbolt.org/z/RMAbWa


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74935/new/

https://reviews.llvm.org/D74935



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D143287: [Clang][X86] Change X86 cast intrinsics to use __builtin_nondeterministic_value

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

H, is D104790  superseded by this patch? I 
wonder what is the status of this patch as well.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143287/new/

https://reviews.llvm.org/D143287

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D143287: [Clang][X86] Change X86 cast intrinsics to use __builtin_nondeterministic_value

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

In D143287#4179344 , @ManuelJBrito 
wrote:

> In D143287#4179020 , @aqjune wrote:
>
>> H, is D104790  superseded by this patch?
>
> I don't think so we still need to fix the undefined intrinsics, right? Maybe 
> I'm not understanding the question.

Oh right, D104790  and this deal with 
different intrinsics, thanks.
I was wondering whether I could clean up some of my open patches.

>> I wonder what is the status of this patch as well.
>
> We need to land D144903  first to have the 
> correct assembly, but it's currently held up by a crash in one of the tests 
> due to an unrelated issue.

I see, hope that the crash is fixed soon..!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143287/new/

https://reviews.llvm.org/D143287

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D144903: [X86] Drop single use check for freeze(undef) in LowerAVXCONCAT_VECTORS

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added inline comments.



Comment at: clang/test/CodeGen/X86/avx-cast-builtins.c:1
 // RUN: %clang_cc1 %s -O3 -flax-vector-conversions=none -ffreestanding %s 
-triple=x86_64-unknown-unknown -target-feature +avx -target-feature +avx512f  
-target-feature +avx512fp16 -S -o - | FileCheck %s
 

This line contains `%s` twice, which seems to cause the crash.

Would removing one of `%s` resolve the crash issue? On my machine removing one 
of those worked well; with two `%s`; it crashed.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D144903/new/

https://reviews.llvm.org/D144903

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D144903: [X86] Drop single use check for freeze(undef) in LowerAVXCONCAT_VECTORS

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added inline comments.



Comment at: clang/test/CodeGen/X86/avx-cast-builtins.c:1
 // RUN: %clang_cc1 %s -O3 -flax-vector-conversions=none -ffreestanding %s 
-triple=x86_64-unknown-unknown -target-feature +avx -target-feature +avx512f  
-target-feature +avx512fp16 -S -o - | FileCheck %s
 

aqjune wrote:
> This line contains `%s` twice, which seems to cause the crash.
> 
> Would removing one of `%s` resolve the crash issue? On my machine removing 
> one of those worked well; with two `%s`; it crashed.
Actually, with FileCheck's argument counted there are three `%s`, but it isn't 
important; I meant two `%s` in clang_cc1's arguments.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D144903/new/

https://reviews.llvm.org/D144903

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D136737: [Draft] [clang] Add builtin_unspecified_value

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune abandoned this revision.
aqjune added a comment.

Closing this as D142388  added a function 
that can be used instead


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136737/new/

https://reviews.llvm.org/D136737

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D101191: [InstCombine] Fully disable select to and/or i1 folding

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added inline comments.



Comment at: llvm/test/Transforms/InstCombine/logical-select.ll:385
+; CHECK-NEXT:[[OR:%.*]] = select i1 [[AND1]], i1 true, i1 [[AND2]]
+; CHECK-NEXT:ret i1 [[OR]]
 ;

nikic wrote:
> It looks like this fold could be salvaged, if we wanted to: 
> https://alive2.llvm.org/ce/z/TpsYAj
Thx, I added the transformation.
If the transformations look good, I'll make it as a separate commit with tests 
and push it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101191/new/

https://reviews.llvm.org/D101191

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D101191: [InstCombine] Fully disable select to and/or i1 folding

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added inline comments.



Comment at: llvm/lib/Transforms/InstCombine/InstCombineSelect.cpp:2680
+// select c, (select a, true, b), false -> select c, a, false
+//   if c implies that b is false. 
+if (match(CondVal, m_Select(m_Value(A), m_One(), m_Value(B))) &&

I guess `isImpliedCondition` is assuming that LHS and RHS are never poison, but 
this transformation is still correct even if c or b is poison.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101191/new/

https://reviews.llvm.org/D101191

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D101191: [InstCombine] Fully disable select to and/or i1 folding

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added inline comments.



Comment at: llvm/test/Transforms/InstCombine/logical-select.ll:385
+; CHECK-NEXT:[[OR:%.*]] = select i1 [[AND1]], i1 true, i1 [[AND2]]
+; CHECK-NEXT:ret i1 [[OR]]
 ;

nikic wrote:
> aqjune wrote:
> > nikic wrote:
> > > It looks like this fold could be salvaged, if we wanted to: 
> > > https://alive2.llvm.org/ce/z/TpsYAj
> > Thx, I added the transformation.
> > If the transformations look good, I'll make it as a separate commit with 
> > tests and push it.
> Could you please split it off into a separate review? Hard to understand 
> impact as part of this change.
It is splitted into D101375



Comment at: 
llvm/test/Transforms/PhaseOrdering/unsigned-multiply-overflow-check.ll:20
 
+; FIXME: noundef should be attached to args
 define i1 @will_not_overflow(i64 %arg, i64 %arg1) {

spatel wrote:
> Any ideas about what it will take to get those argument attributes for the 
> C++ source example shown in the code comment?
> 
> SDAG is still going to convert the `select` to `and`, so we can probably 
> avoid regressions by replicating InstSimplify's 
> omitCheckForZeroBeforeMulWithOverflow() as a DAG combine. Let me know if I 
> should do that.
I promised to do the patch at D82317, but these days I'm occupied with other 
things, so it might not be a recent future (not in a month at least)...

I think it is a good chance to use freeze here: We can add
```
%cond = icmp ne %x, 0
%v = call @llvm.umul.with.overflow(%x, %y)
%ov = extractvalue %v, 1
%res = select i1 %cond, %ov, false
  =>
%y.fr = freeze %y
%v = call @llvm.umul.with.overflow(%x, %y.fr)
%ov = extractvalue %v, 1
%res = %ov
```
into CodeGenPrepare.
What do you think? CodeGenPrepare is already using freeze for a few 
transformations.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101191/new/

https://reviews.llvm.org/D101191

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D101191: [InstCombine] Fully disable select to and/or i1 folding

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added inline comments.



Comment at: 
llvm/test/Transforms/PhaseOrdering/unsigned-multiply-overflow-check.ll:20
 
+; FIXME: noundef should be attached to args
 define i1 @will_not_overflow(i64 %arg, i64 %arg1) {

aqjune wrote:
> spatel wrote:
> > Any ideas about what it will take to get those argument attributes for the 
> > C++ source example shown in the code comment?
> > 
> > SDAG is still going to convert the `select` to `and`, so we can probably 
> > avoid regressions by replicating InstSimplify's 
> > omitCheckForZeroBeforeMulWithOverflow() as a DAG combine. Let me know if I 
> > should do that.
> I promised to do the patch at D82317, but these days I'm occupied with other 
> things, so it might not be a recent future (not in a month at least)...
> 
> I think it is a good chance to use freeze here: We can add
> ```
> %cond = icmp ne %x, 0
> %v = call @llvm.umul.with.overflow(%x, %y)
> %ov = extractvalue %v, 1
> %res = select i1 %cond, %ov, false
>   =>
> %y.fr = freeze %y
> %v = call @llvm.umul.with.overflow(%x, %y.fr)
> %ov = extractvalue %v, 1
> %res = %ov
> ```
> into CodeGenPrepare.
> What do you think? CodeGenPrepare is already using freeze for a few 
> transformations.
Alive2 proof: https://alive2.llvm.org/ce/z/zgPUGT


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101191/new/

https://reviews.llvm.org/D101191

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D101191: [InstCombine] Fully disable select to and/or i1 folding

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added inline comments.



Comment at: 
llvm/test/Transforms/PhaseOrdering/unsigned-multiply-overflow-check.ll:20
 
+; FIXME: noundef should be attached to args
 define i1 @will_not_overflow(i64 %arg, i64 %arg1) {

nikic wrote:
> spatel wrote:
> > aqjune wrote:
> > > aqjune wrote:
> > > > spatel wrote:
> > > > > Any ideas about what it will take to get those argument attributes 
> > > > > for the C++ source example shown in the code comment?
> > > > > 
> > > > > SDAG is still going to convert the `select` to `and`, so we can 
> > > > > probably avoid regressions by replicating InstSimplify's 
> > > > > omitCheckForZeroBeforeMulWithOverflow() as a DAG combine. Let me know 
> > > > > if I should do that.
> > > > I promised to do the patch at D82317, but these days I'm occupied with 
> > > > other things, so it might not be a recent future (not in a month at 
> > > > least)...
> > > > 
> > > > I think it is a good chance to use freeze here: We can add
> > > > ```
> > > > %cond = icmp ne %x, 0
> > > > %v = call @llvm.umul.with.overflow(%x, %y)
> > > > %ov = extractvalue %v, 1
> > > > %res = select i1 %cond, %ov, false
> > > >   =>
> > > > %y.fr = freeze %y
> > > > %v = call @llvm.umul.with.overflow(%x, %y.fr)
> > > > %ov = extractvalue %v, 1
> > > > %res = %ov
> > > > ```
> > > > into CodeGenPrepare.
> > > > What do you think? CodeGenPrepare is already using freeze for a few 
> > > > transformations.
> > > Alive2 proof: https://alive2.llvm.org/ce/z/zgPUGT
> > I don't think we want to add code to CGP if we can avoid it. CGP is 
> > supposed to be a temporary hack that is not needed with GlobalISel. I do 
> > acknowledge that "temporary" in the code may outlive the people working on 
> > it today (!).
> > 
> > If we don't care about undef correctness in codegen (in other words, the 
> > select->and transform will live on in codegen forever), then we might as 
> > well add a DAG combine. Alternatively, are we comfortable creating freeze 
> > in instcombine for rare code like umul.with.ov?
> I think this is one of the rare cases where inserting Freeze in InstCombine 
> makes sense. There's not much (any?) further optimization opportunities for a 
> umul.with.overflow with non-constant operands.
InstCombine sounds good as well!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101191/new/

https://reviews.llvm.org/D101191

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D101191: [InstCombine] Fully disable select to and/or i1 folding

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

I found that there are a few more patterns that can be salvaged. Will create a 
patch for them.




Comment at: llvm/test/Transforms/InstCombine/and.ll:898
 ; CHECK-NEXT:[[Y:%.*]] = icmp ugt i72 [[C:%.*]], 42
-; CHECK-NEXT:[[AND:%.*]] = and i1 [[X]], [[Y]]
 ; CHECK-NEXT:ret i1 [[AND]]

This can be resurrected.



Comment at: llvm/test/Transforms/InstCombine/and.ll:1033
 ; CHECK-NEXT:[[Y:%.*]] = icmp ugt i32 [[C:%.*]], 42
-; CHECK-NEXT:[[AND:%.*]] = and i1 [[Y]], [[X_INV]]
 ; CHECK-NEXT:ret i1 [[AND]]

This can be resurrected as well.



Comment at: llvm/test/Transforms/InstCombine/and2.ll:51
-; CHECK-NEXT:[[TMP2:%.*]] = and i1 [[TMP1]], [[B:%.*]]
-; CHECK-NEXT:ret i1 [[TMP2]]
 ;

This one too



Comment at: llvm/test/Transforms/PGOProfile/chr.ll:1374
 ; CHECK-NEXT:[[V0:%.*]] = icmp eq i32 [[Z:%.*]], 0
-; CHECK-NEXT:[[V3:%.*]] = and i1 [[V0]], [[PRED:%.*]]
 ; CHECK-NEXT:br i1 [[V3]], label [[BB0:%.*]], label [[BB1:%.*]], !prof !16

This one as well


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101191/new/

https://reviews.llvm.org/D101191

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D101191: [InstCombine] Fully disable select to and/or i1 folding

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

I made D101720  to cover the remaining cases 
except `Transforms/InstCombine/and2.ll`.
Supporting `and2.ll` doesn't seem super-straightforward, but maybe some minor 
tweaks can make it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101191/new/

https://reviews.llvm.org/D101191

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D101191: [InstCombine] Fully disable select to and/or i1 folding

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

(BTW, if the patch is reviewed, then I believe we are finally ready to land 
this patch.)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101191/new/

https://reviews.llvm.org/D101191

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D101191: [InstCombine] Fully disable select to and/or i1 folding

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added inline comments.



Comment at: llvm/test/Transforms/InstCombine/or.ll:1102
+; CHECK-NEXT:[[AND:%.*]] = select i1 [[Y]], i1 [[X]], i1 false
+; CHECK-NEXT:[[OR:%.*]] = select i1 [[X_INV]], i1 true, i1 [[AND]]
 ; CHECK-NEXT:ret i1 [[OR]]

nikic wrote:
> Can be salvaged: https://alive2.llvm.org/ce/z/-STJ2d
> 
> I thought this was already covered by one of the folds though...
No, it didn't exist.
I think there are too many possible combinations here. It should be reduced 
into more compact code someday...
Made a patch here: D101807


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101191/new/

https://reviews.llvm.org/D101191

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D101191: [InstCombine] Fully disable select to and/or i1 folding

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added inline comments.



Comment at: llvm/test/Transforms/InstCombine/or.ll:1135
 ; CHECK-NEXT:ret i1 [[OR]]
 ;
   %x = icmp sge i16 %a, %b

This can be salvaged as well: 
https://alive2.llvm.org/ce/z/yXF96T

But I think there are more patterns that are missing. I'll leave them as 
missing optimization opportunities at bugzilla after this patch is reviewed.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101191/new/

https://reviews.llvm.org/D101191

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D101191: [InstCombine] Fully disable select to and/or i1 folding

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

I think this patch is ready to go: running the test-suite on an ARM machine 
didn't complain anything.

Well, but one thing that I'm concerned about is that from tomorrow I'll not be 
online for about three weeks. :(

I'd like to find someone who reverts this patch if there is any serious problem.




Comment at: llvm/test/Transforms/InstCombine/or.ll:1135
 ; CHECK-NEXT:ret i1 [[OR]]
 ;
   %x = icmp sge i16 %a, %b

aqjune wrote:
> This can be salvaged as well: 
> https://alive2.llvm.org/ce/z/yXF96T
> 
> But I think there are more patterns that are missing. I'll leave them as 
> missing optimization opportunities at bugzilla after this patch is reviewed.
Addressed via D101801


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101191/new/

https://reviews.llvm.org/D101191

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D101191: [InstCombine] Fully disable select to and/or i1 folding

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

In D101191#2738130 , @nikic wrote:

> LGTM. I can take care of reverting if there are issues.

Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101191/new/

https://reviews.llvm.org/D101191

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D93793: [IR] Let IRBuilder's CreateVectorSplat/CreateShuffleVector use poison as placeholder

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

In D93793#3221414 , @Allen wrote:

> I have a babyism question, why poison is preferred to the undef in the 
> pattern ConstantVector::getSplat ?

Hi Allen,
It is because folding poison is easier than folding undef. :)
For example, according to the poison propagating rule, 'and i32 poison, 1' can 
be simplified into 'i32 poison'. However, 'and undef, 1' cannot be folded into 
'undef' since the mask enforces all bits but LSB 0. 
This patch helps simplifications happen more easily.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93793/new/

https://reviews.llvm.org/D93793

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D115804: [CodeGen] use saturating FP casts when compiling with "no-strict-float-cast-overflow"

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

This sounds like a great fix to me! :)


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D115804/new/

https://reviews.llvm.org/D115804

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D82317: [Clang/Test]: Update tests where `noundef` attribute is necessary

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.
Herald added a subscriber: lxfind.

Hello all,
Is there a plan to enable `-enable-noundef-analysis` by default? It seems this 
patch is already addressing a lot of test cases.
Another good news is that DeadArgElim is also fixed by D98899 
 to correctly drop UB-raising attributes such 
as noundef when replacing an unused argument with undef. This was an issue 
which is known to be problematic when the flag was activated.
I can make a patch based on this work instead if people want.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D82317/new/

https://reviews.llvm.org/D82317

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D82317: [Clang/Test]: Update tests where `noundef` attribute is necessary

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

Thank you all! Incremental change makes sense to me as well. It will help 
smooth landing without buildbot failures.
I'll start writing patches soon.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D82317/new/

https://reviews.llvm.org/D82317

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D93586: [InstCombine] use poison as placeholder for undemanded elems

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

There are 3 more patches:

https://reviews.llvm.org/D93793 (IRBuilder's CreateVectorSplat)
https://reviews.llvm.org/D93817 (Other transformations) 
https://reviews.llvm.org/D93818 (LangRef)

Would it be desirable if I land all of these at once as well as this (93586) 
when they are accepted, or is incrementally landing accepted patches okay?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93586/new/

https://reviews.llvm.org/D93586

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D93793: [IR] Let IRBuilder's CreateVectorSplat use poison as inselt's placeholder

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added inline comments.



Comment at: llvm/lib/IR/IRBuilder.cpp:1021
   Value *Zeros = ConstantAggregateZero::get(VectorType::get(I32Ty, EC));
   return CreateShuffleVector(V, Undef, Zeros, Name + ".splat");
 }

nikic wrote:
> aqjune wrote:
> > nlopes wrote:
> > > while at it, don't you want to change this one to poison as well?
> > It would be great, but there are many other places that create 
> > shufflevector with undef args (InstCombineCalls, etc). Since this and 
> > related patches are big changes, I think it might be good to land these 
> > first.
> I think in this case it makes sense to change both at once, as it's part of 
> one construction. It's odd that one uses undef and the other poison, even 
> though both are equally non-demanded.
If the relevant patches are to be landed at once, I think the series of patches 
are being too big to maintain... :(
I'd like to make shufflevector's placeholder as poison in another iteration.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93793/new/

https://reviews.llvm.org/D93793

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D93586: [InstCombine] use poison as placeholder for undemanded elems

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

Okay, I'll gently land this.
I was just wondering whether insertelements having heterogenous placeholder 
would be problematic (this patch makes some of insertelement use poison, but 
not all), but it may not matter very much.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93586/new/

https://reviews.llvm.org/D93586

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D93793: [IR] Let IRBuilder's CreateVectorSplat use poison as inselt's placeholder

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added inline comments.



Comment at: llvm/lib/IR/IRBuilder.cpp:1021
   Value *Zeros = ConstantAggregateZero::get(VectorType::get(I32Ty, EC));
   return CreateShuffleVector(V, Undef, Zeros, Name + ".splat");
 }

aqjune wrote:
> nikic wrote:
> > aqjune wrote:
> > > nlopes wrote:
> > > > while at it, don't you want to change this one to poison as well?
> > > It would be great, but there are many other places that create 
> > > shufflevector with undef args (InstCombineCalls, etc). Since this and 
> > > related patches are big changes, I think it might be good to land these 
> > > first.
> > I think in this case it makes sense to change both at once, as it's part of 
> > one construction. It's odd that one uses undef and the other poison, even 
> > though both are equally non-demanded.
> If the relevant patches are to be landed at once, I think the series of 
> patches are being too big to maintain... :(
> I'd like to make shufflevector's placeholder as poison in another iteration.
Okay, I'll copy tests that have poison as shufflevector's placeholder value as 
well (will have the *-inseltpoison.ll suffix too) & update this patch.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93793/new/

https://reviews.llvm.org/D93793

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D93793: [IR] Let IRBuilder's CreateVectorSplat use poison as inselt's placeholder

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune updated this revision to Diff 313945.
aqjune added a comment.
Herald added subscribers: kerbowa, nhaehnle, jvesely.

Update IRBuilder to fill poison at shufflevector's empty operand


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93793/new/

https://reviews.llvm.org/D93793

Files:
  clang/test/CodeGen/SystemZ/builtins-systemz-zvector-constrained.c
  clang/test/CodeGen/SystemZ/builtins-systemz-zvector.c
  clang/test/CodeGen/SystemZ/builtins-systemz-zvector2-constrained.c
  clang/test/CodeGen/SystemZ/builtins-systemz-zvector2.c
  clang/test/CodeGen/SystemZ/zvector.c
  clang/test/CodeGen/arm-mve-intrinsics/compare.c
  clang/test/CodeGen/arm-mve-intrinsics/cplusplus.cpp
  clang/test/CodeGen/arm-mve-intrinsics/dup.c
  clang/test/CodeGen/arm-mve-intrinsics/ternary.c
  clang/test/CodeGen/arm-mve-intrinsics/vaddq.c
  clang/test/CodeGen/arm-mve-intrinsics/vhaddq.c
  clang/test/CodeGen/arm-mve-intrinsics/vhsubq.c
  clang/test/CodeGen/arm-mve-intrinsics/vmulq.c
  clang/test/CodeGen/arm-mve-intrinsics/vqaddq.c
  clang/test/CodeGen/arm-mve-intrinsics/vqdmulhq.c
  clang/test/CodeGen/arm-mve-intrinsics/vqdmullbq.c
  clang/test/CodeGen/arm-mve-intrinsics/vqdmulltq.c
  clang/test/CodeGen/arm-mve-intrinsics/vqrdmulhq.c
  clang/test/CodeGen/arm-mve-intrinsics/vqsubq.c
  clang/test/CodeGen/arm-mve-intrinsics/vsubq.c
  clang/test/CodeGen/builtins-ppc-p10vector.c
  clang/test/CodeGen/matrix-type-operators.c
  clang/test/CodeGen/vecshift.c
  clang/test/CodeGenCXX/matrix-type-operators.cpp
  clang/test/CodeGenCXX/vector-conditional.cpp
  clang/test/CodeGenCXX/vector-splat-conversion.cpp
  clang/test/CodeGenOpenCL/bool_cast.cl
  clang/test/CodeGenOpenCL/shifts.cl
  llvm/include/llvm/IR/IRBuilder.h
  llvm/lib/IR/IRBuilder.cpp
  llvm/test/Transforms/InstCombine/X86/x86-vector-shifts-inseltpoison.ll
  llvm/test/Transforms/InstCombine/X86/x86-vector-shifts.ll
  llvm/test/Transforms/InstCombine/gep-inbounds-null.ll
  llvm/test/Transforms/InstCombine/getelementptr.ll
  llvm/test/Transforms/InstCombine/shuffle-select-narrow-inseltpoison.ll
  llvm/test/Transforms/InstCombine/shuffle-select-narrow.ll
  llvm/test/Transforms/InstCombine/type_pun-inseltpoison.ll
  llvm/test/Transforms/InstCombine/type_pun.ll
  llvm/test/Transforms/InstCombine/vec_shuffle-inseltpoison.ll
  llvm/test/Transforms/InstCombine/vec_shuffle.ll
  llvm/test/Transforms/InstCombine/vscale_cmp.ll
  llvm/test/Transforms/LoopVectorize/AArch64/arbitrary-induction-step.ll
  
llvm/test/Transforms/LoopVectorize/AArch64/outer_loop_test1_no_explicit_vect_width.ll
  llvm/test/Transforms/LoopVectorize/ARM/mve-gather-scatter-tailpred.ll
  llvm/test/Transforms/LoopVectorize/ARM/mve-reduction-types.ll
  llvm/test/Transforms/LoopVectorize/ARM/pointer_iv.ll
  llvm/test/Transforms/LoopVectorize/ARM/tail-folding-not-allowed.ll
  llvm/test/Transforms/LoopVectorize/PowerPC/optimal-epilog-vectorization.ll
  llvm/test/Transforms/LoopVectorize/X86/consecutive-ptr-uniforms.ll
  llvm/test/Transforms/LoopVectorize/X86/constant-fold.ll
  llvm/test/Transforms/LoopVectorize/X86/cost-model-assert.ll
  llvm/test/Transforms/LoopVectorize/X86/interleaving.ll
  llvm/test/Transforms/LoopVectorize/X86/invariant-load-gather.ll
  llvm/test/Transforms/LoopVectorize/X86/invariant-store-vectorization.ll
  llvm/test/Transforms/LoopVectorize/X86/load-deref-pred.ll
  llvm/test/Transforms/LoopVectorize/X86/masked_load_store.ll
  llvm/test/Transforms/LoopVectorize/X86/metadata-enable.ll
  llvm/test/Transforms/LoopVectorize/X86/optsize.ll
  
llvm/test/Transforms/LoopVectorize/X86/outer_loop_test1_no_explicit_vect_width.ll
  llvm/test/Transforms/LoopVectorize/X86/pr34438.ll
  llvm/test/Transforms/LoopVectorize/X86/small-size.ll
  llvm/test/Transforms/LoopVectorize/X86/tail_loop_folding.ll
  llvm/test/Transforms/LoopVectorize/X86/uniform_mem_op.ll
  llvm/test/Transforms/LoopVectorize/X86/vect.omp.force.small-tc.ll
  
llvm/test/Transforms/LoopVectorize/X86/x86-interleaved-accesses-masked-group.ll
  llvm/test/Transforms/LoopVectorize/consecutive-ptr-uniforms.ll
  llvm/test/Transforms/LoopVectorize/dont-fold-tail-for-const-TC.ll
  llvm/test/Transforms/LoopVectorize/dont-fold-tail-for-divisible-TC.ll
  llvm/test/Transforms/LoopVectorize/first-order-recurrence-complex.ll
  llvm/test/Transforms/LoopVectorize/float-induction.ll
  llvm/test/Transforms/LoopVectorize/float-minmax-instruction-flag.ll
  llvm/test/Transforms/LoopVectorize/if-pred-stores.ll
  llvm/test/Transforms/LoopVectorize/induction-step.ll
  llvm/test/Transforms/LoopVectorize/induction.ll
  llvm/test/Transforms/LoopVectorize/interleaved-accesses-1.ll
  llvm/test/Transforms/LoopVectorize/interleaved-accesses-pred-stores.ll
  llvm/test/Transforms/LoopVectorize/interleaved-accesses.ll
  llvm/test/Transforms/LoopVectorize/invariant-store-vectorization.ll
  llvm/test/Transforms/LoopVectorize/loop-form.ll
  llvm/test/Transforms/LoopVectorize/minmax_reduction.ll
  llvm/test/Transforms/LoopVectorize/multiple-strides

[PATCH] D93793: [IR] Let IRBuilder's CreateVectorSplat/CreateShuffleVector use poison as placeholder

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added inline comments.



Comment at: clang/test/CodeGen/SystemZ/builtins-systemz-zvector-constrained.c:84
   vd = vec_splat(vd, 1);
   // CHECK: shufflevector <2 x double> %{{.*}}, <2 x double> undef, <2 x i32> 

   // CHECK-ASM: vrepg

These SystemZ zvector tests are still creating shufflevector with undef, and I 
couldn't find where they stem from. :/ 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93793/new/

https://reviews.llvm.org/D93793

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D93793: [IR] Let IRBuilder's CreateVectorSplat/CreateShuffleVector use poison as placeholder

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune updated this revision to Diff 313989.
aqjune added a comment.
Herald added a reviewer: bollu.

Update comments
Call unary CreateShuffleVector
Update polly tests


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93793/new/

https://reviews.llvm.org/D93793

Files:
  clang/test/CodeGen/SystemZ/builtins-systemz-zvector-constrained.c
  clang/test/CodeGen/SystemZ/builtins-systemz-zvector.c
  clang/test/CodeGen/SystemZ/builtins-systemz-zvector2-constrained.c
  clang/test/CodeGen/SystemZ/builtins-systemz-zvector2.c
  clang/test/CodeGen/SystemZ/zvector.c
  clang/test/CodeGen/arm-mve-intrinsics/compare.c
  clang/test/CodeGen/arm-mve-intrinsics/cplusplus.cpp
  clang/test/CodeGen/arm-mve-intrinsics/dup.c
  clang/test/CodeGen/arm-mve-intrinsics/ternary.c
  clang/test/CodeGen/arm-mve-intrinsics/vaddq.c
  clang/test/CodeGen/arm-mve-intrinsics/vhaddq.c
  clang/test/CodeGen/arm-mve-intrinsics/vhsubq.c
  clang/test/CodeGen/arm-mve-intrinsics/vmulq.c
  clang/test/CodeGen/arm-mve-intrinsics/vqaddq.c
  clang/test/CodeGen/arm-mve-intrinsics/vqdmulhq.c
  clang/test/CodeGen/arm-mve-intrinsics/vqdmullbq.c
  clang/test/CodeGen/arm-mve-intrinsics/vqdmulltq.c
  clang/test/CodeGen/arm-mve-intrinsics/vqrdmulhq.c
  clang/test/CodeGen/arm-mve-intrinsics/vqsubq.c
  clang/test/CodeGen/arm-mve-intrinsics/vsubq.c
  clang/test/CodeGen/builtins-ppc-p10vector.c
  clang/test/CodeGen/matrix-type-operators.c
  clang/test/CodeGen/vecshift.c
  clang/test/CodeGenCXX/matrix-type-operators.cpp
  clang/test/CodeGenCXX/vector-conditional.cpp
  clang/test/CodeGenCXX/vector-splat-conversion.cpp
  clang/test/CodeGenOpenCL/bool_cast.cl
  clang/test/CodeGenOpenCL/shifts.cl
  llvm/include/llvm/IR/IRBuilder.h
  llvm/lib/IR/IRBuilder.cpp
  llvm/test/Transforms/InstCombine/X86/x86-vector-shifts-inseltpoison.ll
  llvm/test/Transforms/InstCombine/X86/x86-vector-shifts.ll
  llvm/test/Transforms/InstCombine/gep-inbounds-null.ll
  llvm/test/Transforms/InstCombine/getelementptr.ll
  llvm/test/Transforms/InstCombine/shuffle-select-narrow-inseltpoison.ll
  llvm/test/Transforms/InstCombine/shuffle-select-narrow.ll
  llvm/test/Transforms/InstCombine/type_pun-inseltpoison.ll
  llvm/test/Transforms/InstCombine/type_pun.ll
  llvm/test/Transforms/InstCombine/vec_shuffle-inseltpoison.ll
  llvm/test/Transforms/InstCombine/vec_shuffle.ll
  llvm/test/Transforms/InstCombine/vscale_cmp.ll
  llvm/test/Transforms/LoopVectorize/AArch64/arbitrary-induction-step.ll
  
llvm/test/Transforms/LoopVectorize/AArch64/outer_loop_test1_no_explicit_vect_width.ll
  llvm/test/Transforms/LoopVectorize/ARM/mve-gather-scatter-tailpred.ll
  llvm/test/Transforms/LoopVectorize/ARM/mve-reduction-types.ll
  llvm/test/Transforms/LoopVectorize/ARM/pointer_iv.ll
  llvm/test/Transforms/LoopVectorize/ARM/tail-folding-not-allowed.ll
  llvm/test/Transforms/LoopVectorize/PowerPC/optimal-epilog-vectorization.ll
  llvm/test/Transforms/LoopVectorize/X86/consecutive-ptr-uniforms.ll
  llvm/test/Transforms/LoopVectorize/X86/constant-fold.ll
  llvm/test/Transforms/LoopVectorize/X86/cost-model-assert.ll
  llvm/test/Transforms/LoopVectorize/X86/interleaving.ll
  llvm/test/Transforms/LoopVectorize/X86/invariant-load-gather.ll
  llvm/test/Transforms/LoopVectorize/X86/invariant-store-vectorization.ll
  llvm/test/Transforms/LoopVectorize/X86/load-deref-pred.ll
  llvm/test/Transforms/LoopVectorize/X86/masked_load_store.ll
  llvm/test/Transforms/LoopVectorize/X86/metadata-enable.ll
  llvm/test/Transforms/LoopVectorize/X86/optsize.ll
  
llvm/test/Transforms/LoopVectorize/X86/outer_loop_test1_no_explicit_vect_width.ll
  llvm/test/Transforms/LoopVectorize/X86/pr34438.ll
  llvm/test/Transforms/LoopVectorize/X86/small-size.ll
  llvm/test/Transforms/LoopVectorize/X86/tail_loop_folding.ll
  llvm/test/Transforms/LoopVectorize/X86/uniform_mem_op.ll
  llvm/test/Transforms/LoopVectorize/X86/vect.omp.force.small-tc.ll
  
llvm/test/Transforms/LoopVectorize/X86/x86-interleaved-accesses-masked-group.ll
  llvm/test/Transforms/LoopVectorize/consecutive-ptr-uniforms.ll
  llvm/test/Transforms/LoopVectorize/dont-fold-tail-for-const-TC.ll
  llvm/test/Transforms/LoopVectorize/dont-fold-tail-for-divisible-TC.ll
  llvm/test/Transforms/LoopVectorize/first-order-recurrence-complex.ll
  llvm/test/Transforms/LoopVectorize/float-induction.ll
  llvm/test/Transforms/LoopVectorize/float-minmax-instruction-flag.ll
  llvm/test/Transforms/LoopVectorize/if-pred-stores.ll
  llvm/test/Transforms/LoopVectorize/induction-step.ll
  llvm/test/Transforms/LoopVectorize/induction.ll
  llvm/test/Transforms/LoopVectorize/interleaved-accesses-1.ll
  llvm/test/Transforms/LoopVectorize/interleaved-accesses-pred-stores.ll
  llvm/test/Transforms/LoopVectorize/interleaved-accesses.ll
  llvm/test/Transforms/LoopVectorize/invariant-store-vectorization.ll
  llvm/test/Transforms/LoopVectorize/loop-form.ll
  llvm/test/Transforms/LoopVectorize/minmax_reduction.ll
  llvm/test/Transforms/LoopVectorize/multiple-strides-vectorization.ll
  l