[PATCH] D61046: Fix compilation warnings when compiling with GCC 7.3

[Nikita Popov via Phabricator via cfe-commits]

nikic added inline comments.



Comment at: llvm/trunk/unittests/IR/ConstantRangeTest.cpp:398-401
+#if defined(__GNUC__) && __GNUC__ >= 7
+// Silence warning: variable 'HaveInterrupt3' set but not used
+(void)&HaveInterrupt3;
+#endif

tstellar wrote:
> Same here, no compiler specific ifdefs.
Just doing an unconditional `(void)HaveInterrupt3;` should be fine here. This 
warning is likely not specific to GCC 7 anyway.


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

https://reviews.llvm.org/D61046



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

[PATCH] D61046: Fix compilation warnings when compiling with GCC 7.3

[Nikita Popov via Phabricator via cfe-commits]

nikic added inline comments.



Comment at: clang/trunk/unittests/AST/ASTImporterTest.cpp:4054
+}
   }
 

shafik wrote:
> aganea wrote:
> > Fixes
> > ```
> > [2097/2979] Building CXX object 
> > tools/clang/unittests/Tooling/CMakeFiles/ToolingTests.dir/LookupTest.cpp.o
> > /mnt/f/svn/clang/unittests/Tooling/LookupTest.cpp: In lambda function:
> > /mnt/f/svn/clang/unittests/Tooling/LookupTest.cpp:220:8: warning: suggest 
> > explicit braces to avoid ambiguous ‘else’ [-Wdangling-else]
> >  if (Type.getDecl()->getQualifiedNameAsString() == "x::y::Old")
> > ^
> > ```
> You mixed up the error messages but I see what is going on.
> 
> So you may want to add a comment since it is not apparent that what is going 
> on is due the `EXPECT_TRUE` macro eventually expanding to an `if..else` which 
> is what is triggering the warning. Since someone may come by in the future 
> and just remove the braces since it is not apparent why they are there.
> 
> Same below as well.
EXPECT_* inside if is quite common, I don't think we should add a comment every 
time it is used.


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

https://reviews.llvm.org/D61046



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

[PATCH] D77341: [DomTree] Replace ChildrenGetter with GraphTraits over GraphDiff.

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

Numbers for the newest version: 
https://llvm-compile-time-tracker.com/compare.php?from=183342c0a9850e60dd7a004b651c83dfb3a7d25e&to=eabcf534fe8760d14c95b40f07c61450c819d643&stat=instructions

This is now a geomean 0.2% regressions, and I don't see any large outliers for 
individual files either (everything is below 2%). So this should be fine now, 
at least where compile-time impact is concerned :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77341



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

[PATCH] D84713: [DominatorTree] Simplify ChildrenGetter.

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

This change had a significant negative compile-time impact: 
https://llvm-compile-time-tracker.com/compare.php?from=0b161def6cacff1a63d3cf1a1efe95b550814d7a&to=e22de4e46d1dd1aacc3a7060d24bcbe89908ba6c&stat=instructions


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84713

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

[PATCH] D77341: [DomTree] Replace ChildrenGetter with GraphTraits over GraphDiff.

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

This change causes a 2.5% compile-time regression across the board, see 
http://llvm-compile-time-tracker.com/compare.php?from=37bcf2df01cfa47e4509a5d225a23e2ca95005e6&to=a90374988e4eb8c50d91e11f4e61cdbd5debb235&stat=instructions.
 Can you please try to find a cheaper way to approach this issue?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77341



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

[PATCH] D77632: [TLI] Per-function fveclib for math library used for vectorization

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

This change causes a ~0.5% compile-time regressions: 
http://llvm-compile-time-tracker.com/compare.php?from=5b18b6e9a84d985c0a907009fb71de7c1943bc88&to=60c642e74be6af86906d9f3d982728be7bd4329f&stat=instructions
 This is quite a lot as these things go, so it would be great if you could 
double check if there's any optimization potential here. In particular I'm 
wondering why this affects normal builds so much, even though they 
(presumably?) don't use any veclib at all.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77632



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

[PATCH] D77632: [TLI] Per-function fveclib for math library used for vectorization

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

I gave D77952  a try (on top of this one), but 
didn't see a significant improvement from that change.

Looking at the callgrind output for compilation of a **small** file, I see 52M 
total instructions, 4 calls to TLII initialization, where addition of the 
vector functions takes up the majority of the time, at 0.7M. Most of the cost 
is in the sorting. 2 of the initialization calls are default-constructed TLII 
without target triple, which seems suspect to me (are we not adding TLI early 
enough, and something pulls it in via analysis dependency?)

So for small files, just registering the vector functions does make up a 
non-trivial fraction of time, and lazy initialization might make sense. This 
isn't the whole truth though: While the largest regressions are indeed on small 
files, there are also quite a few > 1% regressions on very large files.

For a mid-size file with ~6000M instructions retried, the main difference I see 
is `TargetLibraryAnalysis::run()` going up from 82M to 126M, with the cost 
coming from the extra `getFnAttribute("veclib")` call in the TargetLibraryInfo 
constructor. Fetching attributes is surprisingly expensive, as it performs an 
iteration over all attributes internally. As this code is iterating over all 
attributes anyway in order to handle `no-builtin-*`, it might make sense to 
move the checks for `"veclib"` and `"no-builtins"` into that loop as well, 
which should make them essentially free.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77632



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

[PATCH] D83013: [LPM] Port CGProfilePass from NPM to LPM

[Nikita Popov via Phabricator via cfe-commits]

nikic requested changes to this revision.
nikic added inline comments.
This revision now requires changes to proceed.



Comment at: llvm/test/Other/opt-O2-pipeline.ll:289
+; CHECK-NEXT: Branch Probability Analysis
+; CHECK-NEXT: Block Frequency Analysis
 ; CHECK-NEXT: FunctionPass Manager

Is it possible to switch this pass to use LazyBPI / LazyBFA, only fetched if 
PGO is actually in use?

PGO functionality that most people don't use adding expensive analysis passes 
like PDT should be avoided.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83013



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

[PATCH] D83013: [LPM] Port CGProfilePass from NPM to LPM

[Nikita Popov via Phabricator via cfe-commits]

nikic added inline comments.



Comment at: llvm/test/Other/opt-O2-pipeline.ll:289
+; CHECK-NEXT: Branch Probability Analysis
+; CHECK-NEXT: Block Frequency Analysis
 ; CHECK-NEXT: FunctionPass Manager

hans wrote:
> nikic wrote:
> > Is it possible to switch this pass to use LazyBPI / LazyBFA, only fetched 
> > if PGO is actually in use?
> > 
> > PGO functionality that most people don't use adding expensive analysis 
> > passes like PDT should be avoided.
> I wonder if just switching to LazyBlockFrequencyInfo would help though. It 
> looks to me like the CGProfile would request info about each function anyway.
> 
> I was surprised to see that Clang sets Opts.CallGraphProfile solely based on 
> whether the integrated assembler is used. Maybe a better fix is to only set 
> that to true when a profile is actually being used?
> I wonder if just switching to LazyBlockFrequencyInfo would help though. It 
> looks to me like the CGProfile would request info about each function anyway.

It would only help if there is some way to only fetch the analysis 
conditionally. I believe many PGO passes use something like 
PSI.hasProfileSummary() or F.hasProfileData() for that.

> I was surprised to see that Clang sets Opts.CallGraphProfile solely based on 
> whether the integrated assembler is used. Maybe a better fix is to only set 
> that to true when a profile is actually being used?

Right, just disabling this by default in clang/opt would also work.

For reference, the current compile-time numbers for this patch: 
https://llvm-compile-time-tracker.com/compare.php?from=516ff1d4baee28b1911737e47b42973567adf8ff&to=8df840660bb764b6653fcfd9ac7a72cc6adebde6&stat=instructions
 Not huge, but it adds up (some similar regressions have been introduced in 
LLVM 10).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83013



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

[PATCH] D83402: ParsedAttrInfo: Change spelling to use StringRef instead of const char*

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

This change looks reasonable to me in terms of coding style, however I'm not 
seeing any compile-time changes in terms of instructions retired myself 
(https://llvm-compile-time-tracker.com/compare.php?from=8691544a276744474ff04b71d7e220069435c7fe&to=75b126ecf7b5a0ce8c04cb46c37b66233854e931&stat=instructions).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83402



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

[PATCH] D83013: [LPM] Port CGProfilePass from NPM to LPM

[Nikita Popov via Phabricator via cfe-commits]

nikic accepted this revision.
nikic added a comment.

LG from my side.

New compile-time numbers: 
https://llvm-compile-time-tracker.com/compare.php?from=0b39d2d75275b80994dac06b7ad05031cbd09393&to=fd070b79e063fff2fad3cd4a467f64dfca83eb90&stat=instructions
 It's nearly neutral now.




Comment at: llvm/test/CodeGen/AMDGPU/opt-pipeline.ll:285
+; GCN-O1-NEXT: Branch Probability Analysis
+; GCN-O1-NEXT: Block Frequency Analysis
 ; GCN-O1-NEXT: FunctionPass Manager

This test is out of date.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83013



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

[PATCH] D77341: [DomTree] Replace ChildrenGetter with GraphTraits over GraphDiff.

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

Numbers for the new patch: 
https://llvm-compile-time-tracker.com/compare.php?from=c0308fd154f9a945608bd42630dc81dce5edfb40&to=e6e3534e77961cfa65d36828de5c75f36a25d009&stat=instructions

The regression is definitely smaller now, but still fairly large. E.g. > 2% on 
mafft.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77341



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

[PATCH] D81728: [InstCombine] Add target-specific inst combining

[Nikita Popov via Phabricator via cfe-commits]

nikic added inline comments.



Comment at: llvm/include/llvm/Analysis/TargetTransformInfo.h:540
+  bool instCombineIntrinsic(InstCombiner &IC, IntrinsicInst &II,
+Instruction **ResultI) const;
+  bool simplifyDemandedUseBitsIntrinsic(InstCombiner &IC, IntrinsicInst &II,

For all three functions, the calling convention seems rather non-idiomatic for 
InstCombine. Rather than having an `Instruction **` argument and bool result, 
is there any reason not to have an `Instruction *` return value, with nullptr 
indicating that the intrinsic couldn't be simplified?



Comment at: llvm/include/llvm/Analysis/TargetTransformInfo.h:542
+  bool simplifyDemandedUseBitsIntrinsic(InstCombiner &IC, IntrinsicInst &II,
+APInt DemandedMask, KnownBits &Known,
+bool &KnownBitsComputed,

`const APInt &DemandedMask`?



Comment at: llvm/include/llvm/Analysis/TargetTransformInfo.h:546
+  bool simplifyDemandedVectorEltsIntrinsic(
+  InstCombiner &IC, IntrinsicInst &II, APInt DemandedElts, APInt 
&UndefElts,
+  APInt &UndefElts2, APInt &UndefElts3,

`const APInt &DemandedElts`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81728



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

[PATCH] D77341: [DomTree] Replace ChildrenGetter with GraphTraits over GraphDiff.

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

In D77341#2144974 , @asbirlea wrote:

> Thank you for the testing. Could you help with with instructions on how to 
> run the tracker myself?
>  My local testing showed a negligible regression for mafft and a negligible 
> improvement on other benchmarks, so it looked like noise on average.


The tracker just compiles test-suite under `perf stat` using the cached cmake 
configs. If I pick out the file with the largest regression (mafft 
`constants.c` in `ReleaseThinLTO` config with 18% regression) I can reproduce 
this locally as follows:

  perf stat /home/nikic/llvm-project/build/bin/clang -DNDEBUG  -O3 
-fomit-frame-pointer -flto=thin -DNDEBUG   -w -Werror=date-time -DLLVM -MD -MT 
MultiSource/Benchmarks/mafft/CMakeFiles/pairlocalalign.dir/constants.c.o -MF 
MultiSource/Benchmarks/mafft/CMakeFiles/pairlocalalign.dir/constants.c.o.d -o 
MultiSource/Benchmarks/mafft/CMakeFiles/pairlocalalign.dir/constants.c.o   -c 
../MultiSource/Benchmarks/mafft/constants.c

This gives me 3.5M instructions before and 4.2M instructions after. Those 
particular numbers are for an assertion-enabled build (the numbers on the 
website are without assertions.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77341



___
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

[Nikita Popov via Phabricator via cfe-commits]

nikic added inline comments.



Comment at: llvm/lib/Transforms/Utils/CodeExtractor.cpp:932
   case Attribute::NoCfCheck:
+  case Attribute::NoUndef:
 break;

Not familiar with this code, but based on the placement of other similar 
attributes like nonnull, this should probably be in the first list.


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] D77621: ADT: SmallVector size & capacity use word-size integers when elements are small.

[Nikita Popov via Phabricator via cfe-commits]

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

I have reverted this change, because it causes a 1% compile-time 

 and memory usage 

 regression. The memory usage regression is probably fine given what this 
change does, but the compile-time regression is not. (For context, this pretty 
much undoes the wins that the recent removal of waymarking gave us.)

Some notes:

- Can you please split out the fix to grow() into a separate revision? It does 
not seem related to the main change, and reduces surface area.
- I don't think the automatic switch of the size/capacity field has been 
justified well. We have plenty of SmallVectors in LLVM that are, indeed, small. 
There is no way an MCRelaxableFragment will ever end up storing a single 
instruction that is 4G large.
- Similarly, I'm not really convinced about handling this in SmallVector at 
all. The original change here just used an `std::vector` in the one place where 
this has become an issue. That seems like a pretty good solution until there is 
evidence that this is really a more widespread problem.

But in any case, my primary concern here is the compile-time regression, and 
it's not immediately clear which part of the change it comes from.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77621



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

[PATCH] D77621: Change BitcodeWriter buffer to std::vector instead of SmallVector.

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

In D77621#157 , @dblaikie wrote:

> @nikic any sense of the noise floor/level on these measurements? It doesn't 
> /look/ like there's much left in this that would cause problems. & I assume 
> these measurements were made on an optimized build (so we don't have to try 
> to improve the unoptimized code?


The measurements are on an optimized build (default LLVM release build, so no 
LTO). The noise level on the "instructions" metric is very low, so that changes 
above 0.1% tend to be significant. The compile-time regression on the original 
change definitely wasn't noise (but the change from D77601 
 is in the noise).

>> Other pieces I see as possibly impacting compile time are:
>> 
>> 1. This correction to SmallVectorTemplateCommon::max_size().   But 
>> SizeTypeMax() is static constexpr, this seems like it could still be 
>> optimized to a constant.
>> 
>>   ```
>> 2. size_type max_size() const { return size_type(-1) / sizeof(T); } +  
>> size_type max_size() const { +return std::min(this->SizeTypeMax(), 
>> size_type(-1) / sizeof(T)); +  } ```
> 
> Perhaps you could move the value computation into a constexpr variable & just 
> return that as needed. (could be a static local constexpr, I guess - to avoid 
> the issues around linkage of constexpr member variables)

The use of a function rather than a static constexpr for SizeTypeMax() was my 
first thought as well. It seems pretty weird to me, but maybe it's enough to 
fall one the wrong side of some inlining heuristic.

The only other thing that comes to mind is that grow_pod() moved into the 
header, which might have negative effects. It should be possible to avoid that 
by providing explicit template instantiations for uint32_t and uintptr_t in the 
cpp file.

I'll try to figure out what the cause is, but might take me a few days.

>> I don't think the automatic switch of the size/capacity field has been 
>> justified well. We have plenty of SmallVectors in LLVM that are, indeed, 
>> small. There is no way an MCRelaxableFragment will ever end up storing a 
>> single instruction that is 4G large.
> 
> @nikic - can you explain the relevance of this ^ (as @dexonsmith pointed out, 
> MCRelaxableFragment doesn't look like it would be affected by this change - 
> is there something we're missing about that?)

MCRelaxableFragment also contains a SmallVector. I used this as an 
example where we use a SmallVector with a very low upper bound on the 
size. (This example is not great, because the structure is already large for 
other reasons.)

>> Similarly, I'm not really convinced about handling this in SmallVector at 
>> all. The original change here just used an std::vector in the one place 
>> where this has become an issue. That seems like a pretty good solution until 
>> there is evidence that this is really a more widespread problem.
> 
> I'm inclined to go with @dexonsmith's perspective here, as the author of the 
> original change & the general attitude that SmallVector should support this 
> kind of use case.

Okay, I'm basically fine with that, if it is our stance that SmallVector should 
always be preferred over std::vector. Not really related to this revision, but 
it would probably help to do some renaming/aliasing to facilitate that view. 
Right now, the number of `SmallVector` uses in LLVM is really small 
compared to the `std::vector` uses (100 vs 6000 based on a not very accurate 
grep). I think part of that is in the name, and calling it `using Vector = 
SmallVector` and `using VectorImpl = SmallVectorImpl` would make it 
a lot more obvious that this is our preferred general purpose vector type, even 
if the stored data is not small.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77621



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

[PATCH] D77621: Change BitcodeWriter buffer to std::vector instead of SmallVector.

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

In D77621#2000237 , @nikic wrote:

> > Perhaps you could move the value computation into a constexpr variable & 
> > just return that as needed. (could be a static local constexpr, I guess - 
> > to avoid the issues around linkage of constexpr member variables)
>
> The use of a function rather than a static constexpr for SizeTypeMax() was my 
> first thought as well. It seems pretty weird to me, but maybe it's enough to 
> fall one the wrong side of some inlining heuristic.
>
> The only other thing that comes to mind is that grow_pod() moved into the 
> header, which might have negative effects. It should be possible to avoid 
> that by providing explicit template instantiations for uint32_t and uintptr_t 
> in the cpp file.
>
> I'll try to figure out what the cause is, but might take me a few days.


I've tried those two things: results 
.
 From the bottom, the first commit is a rebased version of the original change, 
the second one makes `SizeTypeMax` a constant instead of a function and the 
last one moves `grow_pod` back into the C++ file (I forgot to replace the 
UINT32_MAX references in grow_pod, but I don't think it has an impact on the 
conclusion). The first change is a `+0.75%` regression, the second is neutral 
and the last one is a `-0.70%` improvement, the remaining difference is likely 
noise. So it looks like the move of `grow_pod` into the header was the culprit.

What is rather peculiar is that the picture is similar for the max-rss numbers 
.
 I believe this is because max-rss is also influenced by the size of the clang 
binary itself, and apparently the move of grow_pod into the header increased it 
a lot. (I should probably collect clang binary size to make this easy to 
verify.) That means that there doesn't seem to be much of an increase in terms 
of actually allocated heap memory due to this change.

Taking the max-rss numbers 

 across all three commits, the only part where memory usage increases 
non-trivially is the LTO `-g` link step, by about ~1%. Possibly some debuginfo 
related stuff uses `SmallVector`.

So tl;dr looks like as long as we keep `grow_pod` outside the header file, this 
change seems to be approximately free in terms of compile-time and memory usage 
both.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77621



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

[PATCH] D77621: ADT: SmallVector size/capacity use word-size integers when elements are small

[Nikita Popov via Phabricator via cfe-commits]

nikic accepted this revision.
nikic added inline comments.



Comment at: llvm/include/llvm/ADT/SmallVector.h:19
 #include "llvm/Support/Compiler.h"
+#include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/MathExtras.h"

Is this include still needed?



Comment at: llvm/include/llvm/ADT/SmallVector.h:84
 
+template  const size_t SmallVectorBase::SizeTypeMax;
+

Is this needed? I don't think it makes a lot of sense to allow odr-use of 
`SizeTypeMax`. As it's a protected member, it's only used in the SmallVector 
implementation, where we control how it is used.



Comment at: llvm/lib/Support/SmallVector.cpp:48
+  // Ensure we can fit the new capacity.
+  // This is only going to be applicable if the when the capacity is 32 bit.
+  if (MinCapacity > SizeTypeMax)

Nit: `if the when` => `if the` or `when`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77621



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

[PATCH] D77621: ADT: SmallVector size/capacity use word-size integers when elements are small

[Nikita Popov via Phabricator via cfe-commits]

nikic added inline comments.



Comment at: llvm/include/llvm/ADT/SmallVector.h:84
 
+template  const size_t SmallVectorBase::SizeTypeMax;
+

dblaikie wrote:
> nikic wrote:
> > Is this needed? I don't think it makes a lot of sense to allow odr-use of 
> > `SizeTypeMax`. As it's a protected member, it's only used in the 
> > SmallVector implementation, where we control how it is used.
> It's used as a parameter to std::min, so it's already odr used & I'd rather 
> not leave it as a trap to walk around even if we addressed that issue.
> 
> I assume if it were a constexpr local in a protected inline function it 
> wouldn't hinder optimizations in any real way?
> It's used as a parameter to std::min, so it's already odr used & I'd rather 
> not leave it as a trap to walk around even if we addressed that issue.

Oh, right you are! In that case this seems fine :)

> I assume if it were a constexpr local in a protected inline function it 
> wouldn't hinder optimizations in any real way?

The change from constexpr function to constexpr static didn't change anything 
performance-wise, so either way works for me.

Another option is:

```
enum : size_t { SizeTypeMax = std::numeric_limits::max() };
```

Kind of sad that in C++14, using an enum is still the only "no nonsense" way to 
declare a constant.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77621



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

[PATCH] D78862: [IR] Convert null-pointer-is-valid into an enum attribute

[Nikita Popov via Phabricator via cfe-commits]

nikic updated this revision to Diff 260105.
nikic added a comment.
Herald added subscribers: cfe-commits, Kayjukh, frgossen, grosul1, Joonsoo, 
liufengdb, lucyrfox, mgester, arpith-jacob, nicolasvasilache, antiagainst, 
shauheen, jpienaar, rriddle, mehdi_amini, asbirlea, jfb, george.burgess.iv.
Herald added a reviewer: jdoerfert.
Herald added a reviewer: sstefan1.
Herald added a reviewer: ftynse.
Herald added a project: clang.

Update tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78862

Files:
  clang/lib/CodeGen/CGCall.cpp
  clang/test/CodeGen/delete-null-pointer-checks.c
  llvm/docs/LangRef.rst
  llvm/include/llvm/Bitcode/LLVMBitCodes.h
  llvm/include/llvm/IR/Attributes.td
  llvm/include/llvm/IR/AutoUpgrade.h
  llvm/lib/AsmParser/LLLexer.cpp
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/AsmParser/LLToken.h
  llvm/lib/Bitcode/Reader/BitcodeReader.cpp
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/IR/Attributes.cpp
  llvm/lib/IR/AutoUpgrade.cpp
  llvm/lib/IR/Function.cpp
  llvm/lib/IR/Verifier.cpp
  llvm/lib/Transforms/Utils/CodeExtractor.cpp
  llvm/test/Analysis/MemorySSA/cyclicphi.ll
  llvm/test/Bitcode/attributes.ll
  llvm/test/Transforms/Attributor/IPConstantProp/PR26044.ll
  llvm/test/Transforms/Attributor/align.ll
  llvm/test/Transforms/Attributor/nocapture-1.ll
  llvm/test/Transforms/Attributor/nonnull.ll
  llvm/test/Transforms/Attributor/norecurse.ll
  llvm/test/Transforms/Attributor/undefined_behavior.ll
  llvm/test/Transforms/CorrelatedValuePropagation/non-null.ll
  llvm/test/Transforms/FunctionAttrs/nocapture.ll
  llvm/test/Transforms/FunctionAttrs/nonnull.ll
  llvm/test/Transforms/GVN/PRE/2018-06-08-pre-load-dbgloc-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/MallocSROA-section-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-1-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-1.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-2-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-2.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-3-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-3.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-4-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-4.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-phi-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-phi.ll
  llvm/test/Transforms/GlobalOpt/load-store-global-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/malloc-promote-1-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/malloc-promote-1.ll
  llvm/test/Transforms/GlobalOpt/malloc-promote-2-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/malloc-promote-2.ll
  llvm/test/Transforms/GlobalOpt/storepointer-compare-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/storepointer-no-null-opt.ll
  llvm/test/Transforms/IPConstantProp/PR26044.ll
  llvm/test/Transforms/Inline/attributes.ll
  llvm/test/Transforms/InstCombine/atomic.ll
  llvm/test/Transforms/InstCombine/invariant.group.ll
  llvm/test/Transforms/InstCombine/invoke.ll
  llvm/test/Transforms/InstCombine/lifetime-no-null-opt.ll
  llvm/test/Transforms/InstCombine/load.ll
  llvm/test/Transforms/InstCombine/mem-deref-bytes.ll
  llvm/test/Transforms/InstCombine/memchr.ll
  llvm/test/Transforms/InstCombine/memcpy-addrspace.ll
  llvm/test/Transforms/InstCombine/memcpy-from-global.ll
  llvm/test/Transforms/InstCombine/memrchr.ll
  llvm/test/Transforms/InstCombine/select.ll
  llvm/test/Transforms/InstCombine/store.ll
  llvm/test/Transforms/InstCombine/strchr-1.ll
  llvm/test/Transforms/InstCombine/strcpy_chk-64.ll
  llvm/test/Transforms/InstCombine/strlen-1.ll
  llvm/test/Transforms/InstCombine/strncat-2.ll
  llvm/test/Transforms/InstCombine/strncmp-1.ll
  llvm/test/Transforms/InstCombine/strrchr-1.ll
  llvm/test/Transforms/InstCombine/strstr-1.ll
  llvm/test/Transforms/InstCombine/wcslen-1.ll
  llvm/test/Transforms/InstSimplify/compare.ll
  llvm/test/Transforms/LoopIdiom/pr28196.ll
  llvm/test/Transforms/LoopVersioning/lcssa.ll
  llvm/test/Transforms/SimplifyCFG/UnreachableEliminate.ll
  llvm/test/Transforms/SimplifyCFG/invoke.ll
  llvm/test/Transforms/SimplifyCFG/phi-undef-loadstore.ll
  llvm/test/Transforms/SimplifyCFG/trap-no-null-opt-debugloc.ll
  llvm/test/Transforms/SimplifyCFG/trapping-load-unreachable.ll
  llvm/test/Transforms/Util/assume-builder.ll
  mlir/test/Target/llvmir.mlir

Index: mlir/test/Target/llvmir.mlir
===
--- mlir/test/Target/llvmir.mlir
+++ mlir/test/Target/llvmir.mlir
@@ -1205,12 +1205,12 @@
 
 // CHECK-LABEL: @passthrough
 // CHECK: #[[ATTR_GROUP:[0-9]*]]
-llvm.func @passthrough() attributes {passthrough = ["noinline", ["alignstack", "4"], "null-pointer-is-valid", ["foo", "bar"]]} {
+llvm.func @passthrough() attributes {passthrough = ["noinline", ["alignstack", "4"], "null_pointer_is_valid", ["foo", "bar"]]} {
   llvm.return
 }
 
 // CHECK: attributes #[[ATTR_GROUP]] = {
 // CHECK-DAG: noinline
 // CHECK-DAG: 

[PATCH] D78862: [IR] Convert null-pointer-is-valid into an enum attribute

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

In D78862#2003684 , @arsenm wrote:

> FWIW I think this attribute should be replaced with a data layout property, 
> so this would eventually be removed


Is this change planned more for the near term or the long term? I'm not really 
familiar with ongoing addrspace related work.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78862



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

[PATCH] D78862: [IR] Convert null-pointer-is-valid into an enum attribute

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

@arsenm If the `null-pointer-is-valid` attribute is moved into the data layout, 
I'm wondering how Clang's `-fno-delete-null-pointer-checks` option would work 
or what it would be replaced with. In Rust it is possible to define a custom 
target, which also defines a custom data-layout, though I think that also needs 
to be compatible with the base target. I couldn't find any information on how 
to use a custom data layout in Clang. As such, I suspect that to preserve 
existing functionality we'd need support //both// for specifying this 
per-addrspace in the DL and as a function attribute.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78862



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

[PATCH] D78862: [IR] Convert null-pointer-is-valid into an enum attribute

[Nikita Popov via Phabricator via cfe-commits]

nikic updated this revision to Diff 261279.
nikic marked an inline comment as done.
nikic added a comment.

Rebase over committed NFC changes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78862

Files:
  clang/lib/CodeGen/CGCall.cpp
  clang/test/CodeGen/delete-null-pointer-checks.c
  llvm/docs/LangRef.rst
  llvm/include/llvm/Bitcode/LLVMBitCodes.h
  llvm/include/llvm/IR/Attributes.td
  llvm/include/llvm/IR/AutoUpgrade.h
  llvm/lib/AsmParser/LLLexer.cpp
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/AsmParser/LLToken.h
  llvm/lib/Bitcode/Reader/BitcodeReader.cpp
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/IR/Attributes.cpp
  llvm/lib/IR/AutoUpgrade.cpp
  llvm/lib/IR/Function.cpp
  llvm/lib/IR/Verifier.cpp
  llvm/lib/Transforms/Utils/CodeExtractor.cpp
  llvm/test/Analysis/MemorySSA/cyclicphi.ll
  llvm/test/Analysis/ValueTracking/assume.ll
  llvm/test/Bitcode/attributes.ll
  llvm/test/Transforms/Attributor/IPConstantProp/PR26044.ll
  llvm/test/Transforms/Attributor/align.ll
  llvm/test/Transforms/Attributor/nocapture-1.ll
  llvm/test/Transforms/Attributor/nonnull.ll
  llvm/test/Transforms/Attributor/norecurse.ll
  llvm/test/Transforms/Attributor/undefined_behavior.ll
  llvm/test/Transforms/CorrelatedValuePropagation/non-null.ll
  llvm/test/Transforms/FunctionAttrs/nocapture.ll
  llvm/test/Transforms/FunctionAttrs/nonnull.ll
  llvm/test/Transforms/GVN/PRE/2018-06-08-pre-load-dbgloc-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/MallocSROA-section-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-1-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-1.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-2-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-2.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-3-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-3.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-4-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-4.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-phi-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-phi.ll
  llvm/test/Transforms/GlobalOpt/load-store-global-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/malloc-promote-1-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/malloc-promote-1.ll
  llvm/test/Transforms/GlobalOpt/malloc-promote-2-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/malloc-promote-2.ll
  llvm/test/Transforms/GlobalOpt/storepointer-compare-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/storepointer-no-null-opt.ll
  llvm/test/Transforms/IPConstantProp/PR26044.ll
  llvm/test/Transforms/Inline/attributes.ll
  llvm/test/Transforms/InstCombine/atomic.ll
  llvm/test/Transforms/InstCombine/invariant.group.ll
  llvm/test/Transforms/InstCombine/invoke.ll
  llvm/test/Transforms/InstCombine/lifetime-no-null-opt.ll
  llvm/test/Transforms/InstCombine/load.ll
  llvm/test/Transforms/InstCombine/mem-deref-bytes.ll
  llvm/test/Transforms/InstCombine/memchr.ll
  llvm/test/Transforms/InstCombine/memcpy-addrspace.ll
  llvm/test/Transforms/InstCombine/memcpy-from-global.ll
  llvm/test/Transforms/InstCombine/memrchr.ll
  llvm/test/Transforms/InstCombine/select.ll
  llvm/test/Transforms/InstCombine/store.ll
  llvm/test/Transforms/InstCombine/strchr-1.ll
  llvm/test/Transforms/InstCombine/strcpy_chk-64.ll
  llvm/test/Transforms/InstCombine/strlen-1.ll
  llvm/test/Transforms/InstCombine/strncat-2.ll
  llvm/test/Transforms/InstCombine/strncmp-1.ll
  llvm/test/Transforms/InstCombine/strrchr-1.ll
  llvm/test/Transforms/InstCombine/strstr-1.ll
  llvm/test/Transforms/InstCombine/wcslen-1.ll
  llvm/test/Transforms/InstSimplify/compare.ll
  llvm/test/Transforms/LoopIdiom/pr28196.ll
  llvm/test/Transforms/LoopVersioning/lcssa.ll
  llvm/test/Transforms/SimplifyCFG/UnreachableEliminate.ll
  llvm/test/Transforms/SimplifyCFG/invoke.ll
  llvm/test/Transforms/SimplifyCFG/phi-undef-loadstore.ll
  llvm/test/Transforms/SimplifyCFG/trap-no-null-opt-debugloc.ll
  llvm/test/Transforms/SimplifyCFG/trapping-load-unreachable.ll
  llvm/test/Transforms/Util/assume-builder.ll
  mlir/test/Target/llvmir.mlir

Index: mlir/test/Target/llvmir.mlir
===
--- mlir/test/Target/llvmir.mlir
+++ mlir/test/Target/llvmir.mlir
@@ -1205,12 +1205,12 @@
 
 // CHECK-LABEL: @passthrough
 // CHECK: #[[ATTR_GROUP:[0-9]*]]
-llvm.func @passthrough() attributes {passthrough = ["noinline", ["alignstack", "4"], "null-pointer-is-valid", ["foo", "bar"]]} {
+llvm.func @passthrough() attributes {passthrough = ["noinline", ["alignstack", "4"], "null_pointer_is_valid", ["foo", "bar"]]} {
   llvm.return
 }
 
 // CHECK: attributes #[[ATTR_GROUP]] = {
 // CHECK-DAG: noinline
 // CHECK-DAG: alignstack=4
-// CHECK-DAG: "null-pointer-is-valid"
+// CHECK-DAG: null_pointer_is_valid
 // CHECK-DAG: "foo"="bar"
Index: llvm/test/Transforms/Util/assume-builder.ll
===
--- llvm/test/Transfor

[PATCH] D77621: ADT: SmallVector size/capacity use word-size integers when elements are small

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

@browneee Looks like LLVM already defines `LLVM_PTR_SIZE` as a more portable 
version of `__SIZEOF_POINTER__`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77621



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

[PATCH] D78862: [IR] Convert null-pointer-is-valid into an enum attribute

[Nikita Popov via Phabricator via cfe-commits]

nikic updated this revision to Diff 261375.
nikic added a comment.

Fix rebase mistake in test


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78862

Files:
  clang/lib/CodeGen/CGCall.cpp
  clang/test/CodeGen/delete-null-pointer-checks.c
  llvm/docs/LangRef.rst
  llvm/include/llvm/Bitcode/LLVMBitCodes.h
  llvm/include/llvm/IR/Attributes.td
  llvm/include/llvm/IR/AutoUpgrade.h
  llvm/lib/AsmParser/LLLexer.cpp
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/AsmParser/LLToken.h
  llvm/lib/Bitcode/Reader/BitcodeReader.cpp
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/IR/Attributes.cpp
  llvm/lib/IR/AutoUpgrade.cpp
  llvm/lib/IR/Function.cpp
  llvm/lib/IR/Verifier.cpp
  llvm/lib/Transforms/Utils/CodeExtractor.cpp
  llvm/test/Analysis/MemorySSA/cyclicphi.ll
  llvm/test/Analysis/ValueTracking/assume.ll
  llvm/test/Bitcode/attributes.ll
  llvm/test/Transforms/Attributor/IPConstantProp/PR26044.ll
  llvm/test/Transforms/Attributor/align.ll
  llvm/test/Transforms/Attributor/nocapture-1.ll
  llvm/test/Transforms/Attributor/nonnull.ll
  llvm/test/Transforms/Attributor/norecurse.ll
  llvm/test/Transforms/Attributor/undefined_behavior.ll
  llvm/test/Transforms/CorrelatedValuePropagation/non-null.ll
  llvm/test/Transforms/FunctionAttrs/nocapture.ll
  llvm/test/Transforms/FunctionAttrs/nonnull.ll
  llvm/test/Transforms/GVN/PRE/2018-06-08-pre-load-dbgloc-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/MallocSROA-section-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-1-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-1.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-2-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-2.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-3-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-3.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-4-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-4.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-phi-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-phi.ll
  llvm/test/Transforms/GlobalOpt/load-store-global-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/malloc-promote-1-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/malloc-promote-1.ll
  llvm/test/Transforms/GlobalOpt/malloc-promote-2-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/malloc-promote-2.ll
  llvm/test/Transforms/GlobalOpt/storepointer-compare-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/storepointer-no-null-opt.ll
  llvm/test/Transforms/IPConstantProp/PR26044.ll
  llvm/test/Transforms/Inline/attributes.ll
  llvm/test/Transforms/InstCombine/atomic.ll
  llvm/test/Transforms/InstCombine/invariant.group.ll
  llvm/test/Transforms/InstCombine/invoke.ll
  llvm/test/Transforms/InstCombine/lifetime-no-null-opt.ll
  llvm/test/Transforms/InstCombine/load.ll
  llvm/test/Transforms/InstCombine/mem-deref-bytes.ll
  llvm/test/Transforms/InstCombine/memchr.ll
  llvm/test/Transforms/InstCombine/memcpy-addrspace.ll
  llvm/test/Transforms/InstCombine/memcpy-from-global.ll
  llvm/test/Transforms/InstCombine/memrchr.ll
  llvm/test/Transforms/InstCombine/select.ll
  llvm/test/Transforms/InstCombine/store.ll
  llvm/test/Transforms/InstCombine/strchr-1.ll
  llvm/test/Transforms/InstCombine/strcpy_chk-64.ll
  llvm/test/Transforms/InstCombine/strlen-1.ll
  llvm/test/Transforms/InstCombine/strncat-2.ll
  llvm/test/Transforms/InstCombine/strncmp-1.ll
  llvm/test/Transforms/InstCombine/strrchr-1.ll
  llvm/test/Transforms/InstCombine/strstr-1.ll
  llvm/test/Transforms/InstCombine/wcslen-1.ll
  llvm/test/Transforms/InstSimplify/compare.ll
  llvm/test/Transforms/LoopIdiom/pr28196.ll
  llvm/test/Transforms/LoopVersioning/lcssa.ll
  llvm/test/Transforms/SimplifyCFG/UnreachableEliminate.ll
  llvm/test/Transforms/SimplifyCFG/invoke.ll
  llvm/test/Transforms/SimplifyCFG/phi-undef-loadstore.ll
  llvm/test/Transforms/SimplifyCFG/trap-no-null-opt-debugloc.ll
  llvm/test/Transforms/SimplifyCFG/trapping-load-unreachable.ll
  llvm/test/Transforms/Util/assume-builder.ll
  mlir/test/Target/llvmir.mlir

Index: mlir/test/Target/llvmir.mlir
===
--- mlir/test/Target/llvmir.mlir
+++ mlir/test/Target/llvmir.mlir
@@ -1205,12 +1205,12 @@
 
 // CHECK-LABEL: @passthrough
 // CHECK: #[[ATTR_GROUP:[0-9]*]]
-llvm.func @passthrough() attributes {passthrough = ["noinline", ["alignstack", "4"], "null-pointer-is-valid", ["foo", "bar"]]} {
+llvm.func @passthrough() attributes {passthrough = ["noinline", ["alignstack", "4"], "null_pointer_is_valid", ["foo", "bar"]]} {
   llvm.return
 }
 
 // CHECK: attributes #[[ATTR_GROUP]] = {
 // CHECK-DAG: noinline
 // CHECK-DAG: alignstack=4
-// CHECK-DAG: "null-pointer-is-valid"
+// CHECK-DAG: null_pointer_is_valid
 // CHECK-DAG: "foo"="bar"
Index: llvm/test/Transforms/Util/assume-builder.ll
===
--- llvm/test/Transforms/Util/assume-builder.ll
+++ llvm/test/Transfor

[PATCH] D84959: [NewPM][LVI] Abandon LVI after CVP

[Nikita Popov via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG25af353b0e74: [NewPM][LVI] Abandon LVI after CVP (authored 
by nikic).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84959

Files:
  clang/test/CodeGen/thinlto-distributed-newpm.ll
  llvm/lib/Transforms/Scalar/CorrelatedValuePropagation.cpp
  llvm/test/Other/new-pm-defaults.ll
  llvm/test/Other/new-pm-thinlto-defaults.ll
  llvm/test/Other/new-pm-thinlto-postlink-pgo-defaults.ll
  llvm/test/Other/new-pm-thinlto-postlink-samplepgo-defaults.ll
  llvm/test/Other/new-pm-thinlto-prelink-pgo-defaults.ll
  llvm/test/Other/new-pm-thinlto-prelink-samplepgo-defaults.ll

Index: llvm/test/Other/new-pm-thinlto-prelink-samplepgo-defaults.ll
===
--- llvm/test/Other/new-pm-thinlto-prelink-samplepgo-defaults.ll
+++ llvm/test/Other/new-pm-thinlto-prelink-samplepgo-defaults.ll
@@ -93,6 +93,7 @@
 ; CHECK-O23SZ-NEXT: Running pass: JumpThreadingPass
 ; CHECK-O23SZ-NEXT: Running analysis: LazyValueAnalysis
 ; CHECK-O23SZ-NEXT: Running pass: CorrelatedValuePropagationPass
+; CHECK-O23SZ-NEXT: Invalidating analysis: LazyValueAnalysis
 ; CHECK-O-NEXT: Running pass: SimplifyCFGPass
 ; CHECK-O3-NEXT: Running pass: AggressiveInstCombinePass
 ; CHECK-O-NEXT: Running pass: InstCombinePass
@@ -152,7 +153,9 @@
 ; CHECK-O-NEXT: Running analysis: DemandedBitsAnalysis
 ; CHECK-O-NEXT: Running pass: InstCombinePass
 ; CHECK-O23SZ-NEXT: Running pass: JumpThreadingPass
+; CHECK-O23SZ-NEXT: Running analysis: LazyValueAnalysis
 ; CHECK-O23SZ-NEXT: Running pass: CorrelatedValuePropagationPass
+; CHECK-O23SZ-NEXT: Invalidating analysis: LazyValueAnalysis
 ; CHECK-O23SZ-NEXT: Running pass: DSEPass
 ; CHECK-O23SZ-NEXT: Starting {{.*}}Function pass manager run
 ; CHECK-O23SZ-NEXT: Running pass: LoopSimplifyPass
Index: llvm/test/Other/new-pm-thinlto-prelink-pgo-defaults.ll
===
--- llvm/test/Other/new-pm-thinlto-prelink-pgo-defaults.ll
+++ llvm/test/Other/new-pm-thinlto-prelink-pgo-defaults.ll
@@ -127,6 +127,7 @@
 ; CHECK-O23SZ-NEXT: Running pass: JumpThreadingPass
 ; CHECK-O23SZ-NEXT: Running analysis: LazyValueAnalysis
 ; CHECK-O23SZ-NEXT: Running pass: CorrelatedValuePropagationPass
+; CHECK-O23SZ-NEXT: Invalidating analysis: LazyValueAnalysis
 ; CHECK-O-NEXT: Running pass: SimplifyCFGPass
 ; CHECK-O3-NEXT: Running pass: AggressiveInstCombinePass
 ; CHECK-O-NEXT: Running pass: InstCombinePass
@@ -196,7 +197,9 @@
 ; CHECK-O-NEXT: Running analysis: DemandedBitsAnalysis
 ; CHECK-O-NEXT: Running pass: InstCombinePass
 ; CHECK-O23SZ-NEXT: Running pass: JumpThreadingPass
+; CHECK-O23SZ-NEXT: Running analysis: LazyValueAnalysis
 ; CHECK-O23SZ-NEXT: Running pass: CorrelatedValuePropagationPass
+; CHECK-O23SZ-NEXT: Invalidating analysis: LazyValueAnalysis
 ; CHECK-O23SZ-NEXT: Running pass: DSEPass
 ; CHECK-O23SZ-NEXT: Starting {{.*}}Function pass manager run
 ; CHECK-O23SZ-NEXT: Running pass: LoopSimplifyPass
@@ -213,10 +216,26 @@
 ; CHECK-O-NEXT: Finished CGSCC pass manager run.
 ; CHECK-O-NEXT: Finished {{.*}}Module pass manager run.
 ; CHECK-O-NEXT: Finished {{.*}}Module pass manager run.
+; CHECK-O23SZ-NEXT: Clearing all analysis results for: 
+; CHECK-O23SZ-NEXT: Invalidating analysis: DominatorTreeAnalysis
+; CHECK-O23SZ-NEXT: Invalidating analysis: MemorySSAAnalysis
+; CHECK-O23SZ-NEXT: Invalidating analysis: LoopAnalysis
+; CHECK-O23SZ-NEXT: Invalidating analysis: PostDominatorTreeAnalysis
+; CHECK-O23SZ-NEXT: Invalidating analysis: BranchProbabilityAnalysis
+; CHECK-O23SZ-NEXT: Invalidating analysis: BlockFrequencyAnalysis
+; CHECK-O23SZ-NEXT: Invalidating analysis: ScalarEvolutionAnalysis
+; CHECK-O23SZ-NEXT: Invalidating analysis: InnerAnalysisManagerProxy
+; CHECK-O23SZ-NEXT: Invalidating analysis: PhiValuesAnalysis
+; CHECK-O23SZ-NEXT: Invalidating analysis: MemoryDependenceAnalysis
+; CHECK-O23SZ-NEXT: Invalidating analysis: DemandedBitsAnalysis
+; CHECK-O3-NEXT: Invalidating analysis: DominanceFrontierAnalysis
+; CHECK-O3-NEXT: Invalidating analysis: RegionInfoAnalysis
+; CHECK-O23SZ-NEXT: Clearing all analysis results for: foo
 ; CHECK-O-NEXT: Running pass: GlobalOptPass
 ; CHECK-O-NEXT: Running analysis: TargetLibraryAnalysis on bar
 ; CHECK-EXT: Running pass: {{.*}}::Bye
 ; CHECK-O-NEXT: Finished {{.*}}Module pass manager run.
+; CHECK-O23SZ-NEXT: Clearing all analysis results for: foo
 ; CHECK-O-NEXT: Running pass: NameAnonGlobalPass
 ; CHECK-O-NEXT: Running pass: PrintModulePass
 
Index: llvm/test/Other/new-pm-thinlto-postlink-samplepgo-defaults.ll
===
--- llvm/test/Other/new-pm-thinlto-postlink-samplepgo-defaults.ll
+++ llvm/test/Other/new-pm-thinlto-postlink-samplepgo-defaults.ll
@@ -94,6 +94,7 @@
 ; CHEC

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

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

D85684  has landed, so we can try reapplying 
this change.


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] D84713: [DominatorTree] Simplify ChildrenGetter.

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

The regression here seems to be because operations on an empty GraphDiff don't 
optimize out. Not going through GraphDiff but using the same basic logic 
(https://github.com/llvm/llvm-project/commit/4c6a5de8131183ff88f52cc3dda67180e31501a1
 -- going through a separate method seems to be necessary for NRVO) we get back 
at least part of it: 
https://llvm-compile-time-tracker.com/compare.php?from=38537307e502c1ac9a09e6f75f9208db1327a0bf&to=4c6a5de8131183ff88f52cc3dda67180e31501a1&stat=instructions


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84713

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

[PATCH] D78862: [IR] Convert null-pointer-is-valid into an enum attribute

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.
Herald added a subscriber: stephenneuendorffer.

Ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78862



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

[PATCH] D75936: Add a Pass to X86 that builds a Condensed CFG for Load Value Injection (LVI) Gadgets [4/6]

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

This change causes a 0.8% compile-time regression for unoptimized builds 
.
 Based on the pipeline test diffs, I expect this is because the new pass 
requests a bunch of analyses, which it most likely (LVI load hardening 
disabled) will not need. Would it be possible to compute the analyses only if 
LVI load hardening is actually enabled?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75936



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

[PATCH] D75936: Add a Pass to X86 that builds a Condensed CFG for Load Value Injection (LVI) Gadgets [4/6]

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

In D75936#2032090 , @craig.topper 
wrote:

> In D75936#2032078 , @sconstab wrote:
>
> > In D75936#2032027 , @nikic wrote:
> >
> > > This change causes a 0.8% compile-time regression for unoptimized builds 
> > > .
> > >  Based on the pipeline test diffs, I expect this is because the new pass 
> > > requests a bunch of analyses, which it most likely (LVI load hardening 
> > > disabled) will not need. Would it be possible to compute the analyses 
> > > only if LVI load hardening is actually enabled?
> >
> >
> > @craig.topper Do you have any ideas on how this could be done?
>
>
> Unfortunately due to LTO the need for LVI hardening is carried as a function 
> attribute. The pass manager system doesn't allow for running different passes 
> per function. So I don't have any good ideas of how to do that.


Hm, I see. One possibility would be to make those analyses lazy, but that's a 
larger change.

Possibly a pragmatic choice would be to not support this feature at O0? It does 
not seem relevant for non-production binaries. The relative impact of a couple 
unnecessary analysis passes is much higher at `O0` than it is at `O3`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75936



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

[PATCH] D78862: [IR] Convert null-pointer-is-valid into an enum attribute

[Nikita Popov via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGf89f7da999f3: [IR] Convert null-pointer-is-valid into an 
enum attribute (authored by nikic).

Changed prior to commit:
  https://reviews.llvm.org/D78862?vs=261375&id=264285#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78862

Files:
  clang/lib/CodeGen/CGCall.cpp
  clang/test/CodeGen/delete-null-pointer-checks.c
  llvm/docs/LangRef.rst
  llvm/include/llvm/Bitcode/LLVMBitCodes.h
  llvm/include/llvm/IR/Attributes.td
  llvm/include/llvm/IR/AutoUpgrade.h
  llvm/lib/AsmParser/LLLexer.cpp
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/AsmParser/LLToken.h
  llvm/lib/Bitcode/Reader/BitcodeReader.cpp
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/IR/Attributes.cpp
  llvm/lib/IR/AutoUpgrade.cpp
  llvm/lib/IR/Function.cpp
  llvm/lib/IR/Verifier.cpp
  llvm/lib/Transforms/Utils/CodeExtractor.cpp
  llvm/test/Analysis/MemorySSA/cyclicphi.ll
  llvm/test/Analysis/ValueTracking/assume.ll
  llvm/test/Bitcode/attributes.ll
  llvm/test/Transforms/Attributor/IPConstantProp/PR26044.ll
  llvm/test/Transforms/Attributor/align.ll
  llvm/test/Transforms/Attributor/nocapture-1.ll
  llvm/test/Transforms/Attributor/nonnull.ll
  llvm/test/Transforms/Attributor/norecurse.ll
  llvm/test/Transforms/Attributor/undefined_behavior.ll
  llvm/test/Transforms/CorrelatedValuePropagation/non-null.ll
  llvm/test/Transforms/FunctionAttrs/nocapture.ll
  llvm/test/Transforms/FunctionAttrs/nonnull.ll
  llvm/test/Transforms/GVN/PRE/2018-06-08-pre-load-dbgloc-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/MallocSROA-section-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-1-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-1.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-2-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-2.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-3-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-3.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-4-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-4.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-phi-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/heap-sra-phi.ll
  llvm/test/Transforms/GlobalOpt/load-store-global-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/malloc-promote-1-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/malloc-promote-1.ll
  llvm/test/Transforms/GlobalOpt/malloc-promote-2-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/malloc-promote-2.ll
  llvm/test/Transforms/GlobalOpt/storepointer-compare-no-null-opt.ll
  llvm/test/Transforms/GlobalOpt/storepointer-no-null-opt.ll
  llvm/test/Transforms/IPConstantProp/PR26044.ll
  llvm/test/Transforms/Inline/attributes.ll
  llvm/test/Transforms/InstCombine/atomic.ll
  llvm/test/Transforms/InstCombine/invariant.group.ll
  llvm/test/Transforms/InstCombine/invoke.ll
  llvm/test/Transforms/InstCombine/lifetime-no-null-opt.ll
  llvm/test/Transforms/InstCombine/load.ll
  llvm/test/Transforms/InstCombine/mem-deref-bytes.ll
  llvm/test/Transforms/InstCombine/memchr.ll
  llvm/test/Transforms/InstCombine/memcpy-addrspace.ll
  llvm/test/Transforms/InstCombine/memcpy-from-global.ll
  llvm/test/Transforms/InstCombine/memrchr.ll
  llvm/test/Transforms/InstCombine/select.ll
  llvm/test/Transforms/InstCombine/store.ll
  llvm/test/Transforms/InstCombine/strchr-1.ll
  llvm/test/Transforms/InstCombine/strcpy_chk-64.ll
  llvm/test/Transforms/InstCombine/strlen-1.ll
  llvm/test/Transforms/InstCombine/strncat-2.ll
  llvm/test/Transforms/InstCombine/strncmp-1.ll
  llvm/test/Transforms/InstCombine/strrchr-1.ll
  llvm/test/Transforms/InstCombine/strstr-1.ll
  llvm/test/Transforms/InstCombine/wcslen-1.ll
  llvm/test/Transforms/InstSimplify/compare.ll
  llvm/test/Transforms/LoopIdiom/pr28196.ll
  llvm/test/Transforms/LoopVersioning/lcssa.ll
  llvm/test/Transforms/SimplifyCFG/UnreachableEliminate.ll
  llvm/test/Transforms/SimplifyCFG/invoke.ll
  llvm/test/Transforms/SimplifyCFG/phi-undef-loadstore.ll
  llvm/test/Transforms/SimplifyCFG/trap-no-null-opt-debugloc.ll
  llvm/test/Transforms/SimplifyCFG/trapping-load-unreachable.ll
  llvm/test/Transforms/Util/assume-builder.ll
  mlir/test/Target/llvmir.mlir

Index: mlir/test/Target/llvmir.mlir
===
--- mlir/test/Target/llvmir.mlir
+++ mlir/test/Target/llvmir.mlir
@@ -1205,12 +1205,12 @@
 
 // CHECK-LABEL: @passthrough
 // CHECK: #[[ATTR_GROUP:[0-9]*]]
-llvm.func @passthrough() attributes {passthrough = ["noinline", ["alignstack", "4"], "null-pointer-is-valid", ["foo", "bar"]]} {
+llvm.func @passthrough() attributes {passthrough = ["noinline", ["alignstack", "4"], "null_pointer_is_valid", ["foo", "bar"]]} {
   llvm.return
 }
 
 // CHECK: attributes #[[ATTR_GROUP]] = {
 // CHECK-DAG: noinline
 // CHECK-DAG: alignstack=4
-// CHECK-DAG: "null-pointer-is-valid"
+// CHECK-DAG: null_pointer_is_valid
 // CHECK-DAG: "foo"="bar"
Index: llvm/te

[PATCH] D131475: [Flang] Use find_program() to find clang-tblgen

[Nikita Popov via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGc04eab8c78e5: [Flang] Use find_program() to find 
clang-tblgen (authored by nikic).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131475

Files:
  clang/CMakeLists.txt
  flang/docs/CMakeLists.txt


Index: flang/docs/CMakeLists.txt
===
--- flang/docs/CMakeLists.txt
+++ flang/docs/CMakeLists.txt
@@ -126,7 +126,7 @@
 ARGS ${CMAKE_CURRENT_BINARY_DIR}/Source/FIR/CreateFIRLangRef.py)
 
   # CLANG_TABLEGEN_EXE variable needs to be set for clang_tablegen to run 
without error
-  set(CLANG_TABLEGEN_EXE clang-tblgen)
+  find_program(CLANG_TABLEGEN_EXE "clang-tblgen" ${LLVM_TOOLS_BINARY_DIR} 
NO_DEFAULT_PATH)
   gen_rst_file_from_td(FlangCommandLineReference.rst -gen-opt-docs 
FlangOptionsDocs.td docs-flang-html)
 endif()
 if (${SPHINX_OUTPUT_MAN})
Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -484,6 +484,9 @@
 
 add_subdirectory(utils/TableGen)
 
+# Export CLANG_TABLEGEN_EXE for use by flang docs.
+set(CLANG_TABLEGEN_EXE "${CLANG_TABLEGEN_EXE}" CACHE INTERNAL "")
+
 add_subdirectory(include)
 
 # All targets below may depend on all tablegen'd files.


Index: flang/docs/CMakeLists.txt
===
--- flang/docs/CMakeLists.txt
+++ flang/docs/CMakeLists.txt
@@ -126,7 +126,7 @@
 ARGS ${CMAKE_CURRENT_BINARY_DIR}/Source/FIR/CreateFIRLangRef.py)
 
   # CLANG_TABLEGEN_EXE variable needs to be set for clang_tablegen to run without error
-  set(CLANG_TABLEGEN_EXE clang-tblgen)
+  find_program(CLANG_TABLEGEN_EXE "clang-tblgen" ${LLVM_TOOLS_BINARY_DIR} NO_DEFAULT_PATH)
   gen_rst_file_from_td(FlangCommandLineReference.rst -gen-opt-docs FlangOptionsDocs.td docs-flang-html)
 endif()
 if (${SPHINX_OUTPUT_MAN})
Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -484,6 +484,9 @@
 
 add_subdirectory(utils/TableGen)
 
+# Export CLANG_TABLEGEN_EXE for use by flang docs.
+set(CLANG_TABLEGEN_EXE "${CLANG_TABLEGEN_EXE}" CACHE INTERNAL "")
+
 add_subdirectory(include)
 
 # All targets below may depend on all tablegen'd files.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D129833: Use @llvm.threadlocal.address intrinsic to access TLS

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

In D129833#3727881 , @ChuanqiXu wrote:

> And I am working on adding Align properties. But I meet problems since the 
> alignment of threadlocal_address intrinsic depends on its argument so we 
> can't set the alignment for its declaration and we probably need to set the 
> alignment for its call, which means we need to set the alignment when in 
> IRBuilder. Do you think this is good?

I think that would be fine. Alternatively, it could be inferred in InstCombine.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129833

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

[PATCH] D132352: Introduce noread_thread_id to address the thread identification problem in coroutines

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

Okay, this is a bit tricky because we have three different things:

1. The noread_thread_id attribute, the lack of which was causing issues with 
intrinsics in the previous version
2. The meaning of the readnone (etc) attributes, which for pragmatic reasons 
has to exclude thread IDs for now
3. The meaning of doesNotReadMemory() etc queries, which in the previous 
version included thread ID accesses, but in the new version require a separate 
call

I think my question here would be why this did not stick with the previous 
implementation approach that also affects doesNotReadMemory and AA queries (and 
thus makes everything "automatically correct"), and only added the 
noread_thread_id attribute to make intrinsic handling more precise?

My general vision for this area was that after D130896 
, we would add ThreadID as an additional 
ModRef location, which gets removed for non-presplit-coroutines due to being 
constant. This would follow the interpretation that the thread ID is part of 
"memory" though, which kind of goes against the approach here.


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

https://reviews.llvm.org/D132352

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

[PATCH] D133316: [OpenMP] Mark -fopenmp-implicit-rpath as NoArgumentUnused

[Nikita Popov via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG71797797f7a7: [OpenMP] Mark -fopenmp-implicit-rpath as 
NoArgumentUnused (authored by nikic).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133316

Files:
  clang/include/clang/Driver/Options.td


Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -4114,7 +4114,8 @@
   LangOpts<"OpenMP">,
   DefaultTrue,
   PosFlag,
-  NegFlag>;
+  NegFlag,
+  BothFlags<[NoArgumentUnused]>>;
 def r : Flag<["-"], "r">, Flags<[LinkerInput,NoArgumentUnused]>,
 Group;
 def save_temps_EQ : Joined<["-", "--"], "save-temps=">, Flags<[CC1Option, 
FlangOption, NoXarchOption]>,


Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -4114,7 +4114,8 @@
   LangOpts<"OpenMP">,
   DefaultTrue,
   PosFlag,
-  NegFlag>;
+  NegFlag,
+  BothFlags<[NoArgumentUnused]>>;
 def r : Flag<["-"], "r">, Flags<[LinkerInput,NoArgumentUnused]>,
 Group;
 def save_temps_EQ : Joined<["-", "--"], "save-temps=">, Flags<[CC1Option, FlangOption, NoXarchOption]>,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D131465: C++/ObjC++: switch to gnu++17 as the default standard

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

I've reverted this change because it causes major llvm-test-suite breakage. You 
likely need to pin many tests to use `-std=c++14`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131465

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

[PATCH] D131465: C++/ObjC++: switch to gnu++17 as the default standard

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

In D131465#3776537 , @MaskRay wrote:

> In D131465#3776515 , @nikic wrote:
>
>> I've reverted this change because it causes major llvm-test-suite breakage. 
>> You likely need to pin many tests to use `-std=c++14`.
>
> https://github.com/llvm/llvm-test-suite/commit/b3a89445dc4aed7ee9825e024c32d417e36a3f13
>  should fix llvm-test-suite.

Thanks!

It looks like the switch to `-std=c++17` has some major compile-time impact: 
http://llvm-compile-time-tracker.com/compare.php?from=047c7aa96dadf8a2c71a29e2df610d628d9e7e3e&to=3e99b8d947ac024831e59be2b604ac67a24fed94&stat=instructions
 The `O0` build of 7zip becomes 80% slower (without codegen changes).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131465

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

[PATCH] D131465: C++/ObjC++: switch to gnu++17 as the default standard

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

In D131465#3776599 , @nikic wrote:

> It looks like the switch to `-std=c++17` has some major compile-time impact: 
> http://llvm-compile-time-tracker.com/compare.php?from=047c7aa96dadf8a2c71a29e2df610d628d9e7e3e&to=3e99b8d947ac024831e59be2b604ac67a24fed94&stat=instructions
>  The `O0` build of 7zip becomes 80% slower (without codegen changes).

I suspect this is due to increased STL size in in C++17. Taking one sample 
file, preprocessed source is 289149 bytes with `-std=gnu++14` and 654888 with 
`-std=gnu++17`. The source size increased by more than a factor of two, so it's 
not very surprising that the parsing time also increased by the same factor.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131465

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

[PATCH] D133405: [Linux] Hack around Linux/sparc

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

> I've been using this hack to work around the Linux/sparc64 compile failure 
> described in Issue #47994, especially since the underlying glibc PR 
> build/27558 doesn't seem to be making progress and some fix is required to 
> have LLVM build on sparc64-unknown-linux-gnu at all, as evidenced on the 
> buildbot.

Didn't this already get fixed by 
https://github.com/bminor/glibc/commit/d0fa09a7701956036ff36f8ca188e9fff81553d8 
upstream? There was also a later fix for the wchar.h header.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133405

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

[PATCH] D133405: [Linux] Hack around Linux/sparc

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

In D133405#3782136 , @glaubitz wrote:

> In D133405#3782092 , @nikic wrote:
>
>>> I've been using this hack to work around the Linux/sparc64 compile failure 
>>> described in Issue #47994, especially since the underlying glibc PR 
>>> build/27558 doesn't seem to be making progress and some fix is required to 
>>> have LLVM build on sparc64-unknown-linux-gnu at all, as evidenced on the 
>>> buildbot.
>>
>> Didn't this already get fixed by 
>> https://github.com/bminor/glibc/commit/d0fa09a7701956036ff36f8ca188e9fff81553d8
>>  upstream? There was also a later fix for the wchar.h header.
>
> Seems it has only been fixed for some headers, see: 
> https://sourceware.org/bugzilla/show_bug.cgi?id=27087

The other issue has also already been fixed in 
https://github.com/bminor/glibc/commit/c7509d49c4e8fa494120c5ead21338559dad16f5 
(and these fixes have been backported to glibc 2.34+).

Are you still seeing any issues with a current glibc?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133405

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

[PATCH] D133800: [Clang 15.0.1] Downgrade implicit int and implicit function declaration to warning only

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

I tested this patch as well and saw the same failures as @mgorny. Here's the 
additional patch I had to apply to make this pass:

  diff --git a/clang/test/CodeGen/PowerPC/builtins-ppc-p8vector.c 
b/clang/test/CodeGen/PowerPC/builtins-ppc-p8vector.c
  index af3d5c7d066b..3c55e63d1bc8 100644
  --- a/clang/test/CodeGen/PowerPC/builtins-ppc-p8vector.c
  +++ b/clang/test/CodeGen/PowerPC/builtins-ppc-p8vector.c
  @@ -143,7 +143,7 @@ void test1() {
 res_vui = vec_mergee(vui, vui);
   // CHECK: @llvm.ppc.altivec.vperm
   // CHECK-LE: @llvm.ppc.altivec.vperm
  -// CHECK-PPC: error: call to undeclared function 'vec_mergee'
  +// CHECK-PPC: warning: call to undeclared function 'vec_mergee'
   
 res_vbll = vec_mergee(vbll, vbll);
   // CHECK: @llvm.ppc.altivec.vperm
  @@ -177,7 +177,7 @@ void test1() {
 res_vui = vec_mergeo(vui, vui);
   // CHECK: @llvm.ppc.altivec.vperm
   // CHECK-LE: @llvm.ppc.altivec.vperm
  -// CHECK-PPC: error: call to undeclared function 'vec_mergeo'
  +// CHECK-PPC: warning: call to undeclared function 'vec_mergeo'
   
 /* vec_cmpeq */
 res_vbll = vec_cmpeq(vbll, vbll);
  diff --git a/clang/test/CodeGen/builtins-arm-msvc-compat-only.c 
b/clang/test/CodeGen/builtins-arm-msvc-compat-only.c
  index 42cc9d70a142..c2b021b31174 100644
  --- a/clang/test/CodeGen/builtins-arm-msvc-compat-only.c
  +++ b/clang/test/CodeGen/builtins-arm-msvc-compat-only.c
  @@ -1,6 +1,6 @@
   // RUN: %clang_cc1 -triple thumbv7-windows -fms-extensions -emit-llvm -o - 
%s \
   // RUN: | FileCheck %s -check-prefix CHECK-MSVC
  -// RUN: not %clang_cc1 -triple armv7-eabi -emit-llvm %s -o /dev/null 2>&1 \
  +// RUN: %clang_cc1 -triple armv7-eabi -emit-llvm %s -o /dev/null 2>&1 \
   // RUN: | FileCheck %s -check-prefix CHECK-EABI
   // REQUIRES: arm-registered-target
   
  @@ -9,7 +9,7 @@ void emit() {
   }
   
   // CHECK-MSVC: call void asm sideeffect ".inst.n 0xDEFE", ""()
  -// CHECK-EABI: error: call to undeclared function '__emit'
  +// CHECK-EABI: warning: call to undeclared function '__emit'
   
   void emit_truncated() {
 __emit(0x); // movs r0, r0
  diff --git a/clang/test/CodeGen/neon-crypto.c 
b/clang/test/CodeGen/neon-crypto.c
  index 916886574416..1b29b1a53096 100644
  --- a/clang/test/CodeGen/neon-crypto.c
  +++ b/clang/test/CodeGen/neon-crypto.c
  @@ -14,7 +14,7 @@
   
   uint8x16_t test_vaeseq_u8(uint8x16_t data, uint8x16_t key) {
 // CHECK-LABEL: @test_vaeseq_u8
  -  // CHECK-NO-CRYPTO: error: call to undeclared function 'vaeseq_u8'
  +  // CHECK-NO-CRYPTO: warning: call to undeclared function 'vaeseq_u8'
 return vaeseq_u8(data, key);
 // CHECK: call <16 x i8> @llvm.{{arm.neon|aarch64.crypto}}.aese(<16 x i8> 
%data, <16 x i8> %key)
   }


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133800

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

[PATCH] D133800: [Clang 15.0.1] Downgrade implicit int and implicit function declaration to warning only

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

@mgorny Yeah, that was a testing fail on my side. I've updated it to a 
hopefully correct version.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133800

___
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

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

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?


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

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

In D103874#3611507 , @aqjune wrote:

> 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>  i32 1, i32 2, i32 3>

How sure are we that we cannot simply use `poison` elements here? I checked 
what the Intel compiler guide has to say on the topic, and it uses the 
following wording. For "undefined" style intrinsics:

> This intrinsic returns a vector of eight single precision floating point 
> elements. The content of the vector is not specified.

For "cast" style intrinsics:

> The lower 128-bits of the 256-bit resulting vector contains the source vector 
> values; the upper 128-bits of the resulting vector are undefined. This 
> intrinsic does not introduce extra moves to the generated code

It's not really clear what "undefined" is supposed to mean here (and how it 
differs from "not specified").

Unless we're aware of a specific problems in this area, I think it's okay to 
start out with just doing the undef -> poison replacement, and possibly 
backtrack if there are real-world assumptions about the specific meaning of 
"undefined" in this context.


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] D125795: [IR] Remove support for extractvalue constant expression

[Nikita Popov 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 rG5548e807b577: [IR] Remove support for extractvalue constant 
expression (authored by nikic).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D125795?vs=439367&id=440531#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125795

Files:
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  llvm/bindings/go/llvm/ir.go
  llvm/bindings/ocaml/llvm/llvm.ml
  llvm/bindings/ocaml/llvm/llvm.mli
  llvm/bindings/ocaml/llvm/llvm_ocaml.c
  llvm/docs/ReleaseNotes.rst
  llvm/include/llvm-c/Core.h
  llvm/include/llvm/Analysis/TargetFolder.h
  llvm/include/llvm/IR/ConstantFolder.h
  llvm/include/llvm/IR/Constants.h
  llvm/lib/Analysis/ConstantFolding.cpp
  llvm/lib/Analysis/InlineCost.cpp
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/IR/Constants.cpp
  llvm/lib/IR/ConstantsContext.h
  llvm/lib/IR/Core.cpp
  llvm/lib/Transforms/Coroutines/CoroElide.cpp
  llvm/lib/Transforms/InstCombine/InstCombineCompares.cpp
  llvm/lib/Transforms/Utils/Evaluator.cpp
  llvm/test/Assembler/insertextractvalue.ll
  llvm/test/Assembler/unsupported-constexprs.ll
  llvm/test/CodeGen/Generic/pr33094.ll
  llvm/test/CodeGen/X86/nonconst-static-ev.ll
  llvm/test/Transforms/InstCombine/cast.ll
  llvm/test/Transforms/InstCombine/pr28725.ll
  llvm/test/Transforms/InstSimplify/pr28725.ll

Index: llvm/test/Transforms/InstSimplify/pr28725.ll
===
--- llvm/test/Transforms/InstSimplify/pr28725.ll
+++ llvm/test/Transforms/InstSimplify/pr28725.ll
@@ -1,12 +1,17 @@
+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
 ; RUN: opt -S -passes=instsimplify < %s | FileCheck %s
 %S = type { i16, i32 }
 
+; InstCombine will be able to fold this into zeroinitializer
 define <2 x i16> @test1() {
+; CHECK-LABEL: @test1(
+; CHECK-NEXT:  entry:
+; CHECK-NEXT:[[E:%.*]] = extractvalue [[S:%.*]] select (i1 icmp eq (i16 extractelement (<2 x i16> bitcast (<1 x i32>  to <2 x i16>), i32 0), i16 0), [[S]] zeroinitializer, [[S]] { i16 0, i32 1 }), 0
+; CHECK-NEXT:[[B:%.*]] = insertelement <2 x i16> , i16 [[E]], i32 0
+; CHECK-NEXT:ret <2 x i16> [[B]]
+;
 entry:
-  %b = insertelement <2 x i16> , i16 extractvalue (%S select (i1 icmp eq (i16 extractelement (<2 x i16> bitcast (<1 x i32>  to <2 x i16>), i32 0), i16 0), %S zeroinitializer, %S { i16 0, i32 1 }), 0), i32 0
+  %e = extractvalue %S select (i1 icmp eq (i16 extractelement (<2 x i16> bitcast (<1 x i32>  to <2 x i16>), i32 0), i16 0), %S zeroinitializer, %S { i16 0, i32 1 }), 0
+  %b = insertelement <2 x i16> , i16 %e, i32 0
   ret <2 x i16> %b
 }
-
-; InstCombine will be able to fold this into zeroinitializer
-; CHECK-LABEL: @test1(
-; CHECK: ret <2 x i16>  bitcast (<1 x i32>  to <2 x i16>), i32 0), i16 0), %S zeroinitializer, %S { i16 0, i32 1 }), 0), i16 0>
Index: llvm/test/Transforms/InstCombine/pr28725.ll
===
--- llvm/test/Transforms/InstCombine/pr28725.ll
+++ llvm/test/Transforms/InstCombine/pr28725.ll
@@ -3,7 +3,8 @@
 
 define <2 x i16> @test1() {
 entry:
-  %b = insertelement <2 x i16> , i16 extractvalue (%S select (i1 icmp eq (i16 extractelement (<2 x i16> bitcast (<1 x i32>  to <2 x i16>), i32 0), i16 0), %S zeroinitializer, %S { i16 0, i32 1 }), 0), i32 0
+  %e = extractvalue %S select (i1 icmp eq (i16 extractelement (<2 x i16> bitcast (<1 x i32>  to <2 x i16>), i32 0), i16 0), %S zeroinitializer, %S { i16 0, i32 1 }), 0
+  %b = insertelement <2 x i16> , i16 %e, i32 0
   ret <2 x i16> %b
 }
 
Index: llvm/test/Transforms/InstCombine/cast.ll
===
--- llvm/test/Transforms/InstCombine/cast.ll
+++ llvm/test/Transforms/InstCombine/cast.ll
@@ -1470,7 +1470,8 @@
 ; LE-LABEL: @PR28745(
 ; LE-NEXT:ret i64 0
 ;
-  %b = zext i32 extractvalue ({ i32 } select (i1 icmp eq (i16 extractelement (<2 x i16> bitcast (<1 x i32>  to <2 x i16>), i32 0), i16 0), { i32 } { i32 1 }, { i32 } zeroinitializer), 0) to i64
+  %e = extractvalue { i32 } select (i1 icmp eq (i16 extractelement (<2 x i16> bitcast (<1 x i32>  to <2 x i16>), i32 0), i16 0), { i32 } { i32 1 }, { i32 } zeroinitializer), 0
+  %b = zext i32 %e to i64
   ret i64 %b
 }
 
Index: llvm/test/CodeGen/X86/nonconst-static-ev.ll
===
--- llvm/test/CodeGen/X86/nonconst-static-ev.ll
+++ /dev/null
@@ -1,8 +0,0 @@
-; RUN: not --crash llc -mtriple=i686-linux-gnu < %s 2> %t
-; RUN: FileCheck --check-prefix=CHECK-ERRORS < %t %s
-
-@0 = global i8 extractvalue ([1 x i8] select (i1 ptrtoint (ptr @1 to i1), [1 x i8] [ i8 1 ], [1 x i8] [ i8 2 ]), 0)
-@1 = external global i32
-
-; CHECK-ERRORS: Unsupported expression in stat

[PATCH] D128792: [ConstExpr] Don't create insertvalue expressions

[Nikita Popov 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 rG9ac386495d3c: [ConstExpr] Don't create insertvalue 
expressions (authored by nikic).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128792

Files:
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  llvm/include/llvm/Analysis/TargetFolder.h
  llvm/include/llvm/IR/ConstantFolder.h
  llvm/lib/Analysis/ConstantFolding.cpp


Index: llvm/lib/Analysis/ConstantFolding.cpp
===
--- llvm/lib/Analysis/ConstantFolding.cpp
+++ llvm/lib/Analysis/ConstantFolding.cpp
@@ -1093,7 +1093,7 @@
   case Instruction::InsertElement:
 return ConstantExpr::getInsertElement(Ops[0], Ops[1], Ops[2]);
   case Instruction::InsertValue:
-return ConstantExpr::getInsertValue(
+return ConstantFoldInsertValueInstruction(
 Ops[0], Ops[1], cast(InstOrCE)->getIndices());
   case Instruction::ShuffleVector:
 return ConstantExpr::getShuffleVector(
Index: llvm/include/llvm/IR/ConstantFolder.h
===
--- llvm/include/llvm/IR/ConstantFolder.h
+++ llvm/include/llvm/IR/ConstantFolder.h
@@ -123,7 +123,7 @@
 auto *CAgg = dyn_cast(Agg);
 auto *CVal = dyn_cast(Val);
 if (CAgg && CVal)
-  return ConstantExpr::getInsertValue(CAgg, CVal, IdxList);
+  return ConstantFoldInsertValueInstruction(CAgg, CVal, IdxList);
 return nullptr;
   }
 
Index: llvm/include/llvm/Analysis/TargetFolder.h
===
--- llvm/include/llvm/Analysis/TargetFolder.h
+++ llvm/include/llvm/Analysis/TargetFolder.h
@@ -133,7 +133,7 @@
 auto *CAgg = dyn_cast(Agg);
 auto *CVal = dyn_cast(Val);
 if (CAgg && CVal)
-  return Fold(ConstantExpr::getInsertValue(CAgg, CVal, IdxList));
+  return ConstantFoldInsertValueInstruction(CAgg, CVal, IdxList);
 return nullptr;
   }
 
Index: clang/lib/CodeGen/ItaniumCXXABI.cpp
===
--- clang/lib/CodeGen/ItaniumCXXABI.cpp
+++ clang/lib/CodeGen/ItaniumCXXABI.cpp
@@ -962,7 +962,9 @@
   else
 dstAdj = llvm::ConstantExpr::getNSWAdd(srcAdj, adj);
 
-  return llvm::ConstantExpr::getInsertValue(src, dstAdj, 1);
+  llvm::Constant *res = ConstantFoldInsertValueInstruction(src, dstAdj, 1);
+  assert(res != nullptr && "Folding must succeed");
+  return res;
 }
 
 llvm::Constant *


Index: llvm/lib/Analysis/ConstantFolding.cpp
===
--- llvm/lib/Analysis/ConstantFolding.cpp
+++ llvm/lib/Analysis/ConstantFolding.cpp
@@ -1093,7 +1093,7 @@
   case Instruction::InsertElement:
 return ConstantExpr::getInsertElement(Ops[0], Ops[1], Ops[2]);
   case Instruction::InsertValue:
-return ConstantExpr::getInsertValue(
+return ConstantFoldInsertValueInstruction(
 Ops[0], Ops[1], cast(InstOrCE)->getIndices());
   case Instruction::ShuffleVector:
 return ConstantExpr::getShuffleVector(
Index: llvm/include/llvm/IR/ConstantFolder.h
===
--- llvm/include/llvm/IR/ConstantFolder.h
+++ llvm/include/llvm/IR/ConstantFolder.h
@@ -123,7 +123,7 @@
 auto *CAgg = dyn_cast(Agg);
 auto *CVal = dyn_cast(Val);
 if (CAgg && CVal)
-  return ConstantExpr::getInsertValue(CAgg, CVal, IdxList);
+  return ConstantFoldInsertValueInstruction(CAgg, CVal, IdxList);
 return nullptr;
   }
 
Index: llvm/include/llvm/Analysis/TargetFolder.h
===
--- llvm/include/llvm/Analysis/TargetFolder.h
+++ llvm/include/llvm/Analysis/TargetFolder.h
@@ -133,7 +133,7 @@
 auto *CAgg = dyn_cast(Agg);
 auto *CVal = dyn_cast(Val);
 if (CAgg && CVal)
-  return Fold(ConstantExpr::getInsertValue(CAgg, CVal, IdxList));
+  return ConstantFoldInsertValueInstruction(CAgg, CVal, IdxList);
 return nullptr;
   }
 
Index: clang/lib/CodeGen/ItaniumCXXABI.cpp
===
--- clang/lib/CodeGen/ItaniumCXXABI.cpp
+++ clang/lib/CodeGen/ItaniumCXXABI.cpp
@@ -962,7 +962,9 @@
   else
 dstAdj = llvm::ConstantExpr::getNSWAdd(srcAdj, adj);
 
-  return llvm::ConstantExpr::getInsertValue(src, dstAdj, 1);
+  llvm::Constant *res = ConstantFoldInsertValueInstruction(src, dstAdj, 1);
+  assert(res != nullptr && "Folding must succeed");
+  return res;
 }
 
 llvm::Constant *
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D129009: [LTO] Fix LTO for aliased IFuncs

[Nikita Popov via Phabricator via cfe-commits]

nikic added inline comments.



Comment at: llvm/lib/Analysis/ModuleSummaryAnalysis.cpp:654
+  // summary for aliasee will not be emitted.
+  if (Aliasee->getValueID() != Value::ValueTy::GlobalIFuncVal) {
+bool NonRenamableLocal = isNonRenamableLocal(A);

MaskRay wrote:
> Use an early return to avoid indenting so many lines.
Also, please use `isa(Aliasee)` instead of inspecting the value ID.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129009

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

[PATCH] D125291: Introduce @llvm.threadlocal.address intrinsic to access TLS variable

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

FWIW the bitcode patch has landed, so implementing the variant using a token 
type should be possible now. I'm not sure whether it's better to start with the 
current patch where the intrinsic is optional, or go directly to the one where 
it is required.




Comment at: llvm/docs/LangRef.rst:24415
+
+  declare ptr @llvm.threadlocal.address(ptr) nounwind readnone willreturn
+

Don't we need to overload this intrinsic by return type, so it works with 
different address spaces?



Comment at: llvm/docs/LangRef.rst:24420
+
+The first argument is pointer, which refers to a thread local variable.
+

Should we enforce here (with a verifier check) that the argument is a 
thread-local global variable? I assume we //don't// want to allow weird things 
like `@llvm.threadlocal.address(c ? @g1 : @g2)` right? (Though I guess, without 
thread-local globals using a token type, nothing would prevent optimizations 
from forming this.)



Comment at: llvm/lib/CodeGen/PreISelIntrinsicLowering.cpp:231
+  Changed |= lowerThreadLocalIntrinsics(F);
+  break;
 }

I don't think this belongs here, this should get dropped by SelectionDAGBuilder.



Comment at: 
llvm/test/Transforms/PreISelIntrinsicLowering/threadlocal_address.ll:1
+; RUN: opt -pre-isel-intrinsic-lowering -opaque-pointers -S -o - < %s | 
FileCheck %s
+

`-opaque-pointers` flag is not necessary.


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

https://reviews.llvm.org/D125291

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

[PATCH] D124159: [SimplifyCFG] Thread branches on same condition in more cases (PR54980)

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

@HanKuanChen Thanks for the report! I've landed a fix for this test case in 
https://github.com/llvm/llvm-project/commit/dc969061c68e62328607d68215ed8b9ef4a1e4b1.
 This is based on making SimplifyCFG behave more like JumpThreading, which does 
not have an infinite loop for this case. Let me know if you see further issues.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124159

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

[PATCH] D128820: [ConstExpr] Don't create div/rem expressions

[Nikita Popov 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 rG935570b2ad80: [ConstExpr] Don't create div/rem 
expressions (authored by nikic).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D128820?vs=442100&id=442295#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128820

Files:
  clang/test/CodeGenCUDA/managed-var.cu
  clang/test/OpenMP/target_data_codegen.cpp
  clang/test/OpenMP/target_enter_data_codegen.cpp
  clang/test/OpenMP/target_enter_data_depend_codegen.cpp
  clang/test/OpenMP/target_exit_data_codegen.cpp
  clang/test/OpenMP/target_exit_data_depend_codegen.cpp
  clang/test/OpenMP/target_update_codegen.cpp
  clang/test/OpenMP/target_update_depend_codegen.cpp
  llvm/include/llvm/Analysis/TargetFolder.h
  llvm/include/llvm/IR/ConstantFolder.h
  llvm/include/llvm/IR/Constants.h
  llvm/lib/Analysis/ConstantFolding.cpp
  llvm/lib/Analysis/ScalarEvolution.cpp
  llvm/lib/IR/ConstantFold.cpp
  llvm/lib/IR/Constants.cpp
  llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp
  llvm/test/Analysis/ScalarEvolution/ptrtoint-constantexpr-loop.ll
  llvm/test/Transforms/InstCombine/not-add.ll

Index: llvm/test/Transforms/InstCombine/not-add.ll
===
--- llvm/test/Transforms/InstCombine/not-add.ll
+++ llvm/test/Transforms/InstCombine/not-add.ll
@@ -172,12 +172,8 @@
 ; CHECK-NEXT:  entry:
 ; CHECK-NEXT:[[XOR:%.*]] = xor i32 [[X:%.*]], 1
 ; CHECK-NEXT:[[B15:%.*]] = srem i32 ashr (i32 65536, i32 or (i32 zext (i1 icmp eq (i32* @g, i32* null) to i32), i32 65537)), [[XOR]]
-; CHECK-NEXT:[[B22:%.*]] = add nsw i32 [[B15]], sdiv (i32 or (i32 zext (i1 icmp eq (i32* @g, i32* null) to i32), i32 65537), i32 2147483647)
-; CHECK-NEXT:[[B14:%.*]] = srem i32 ashr (i32 65536, i32 or (i32 zext (i1 icmp eq (i32* @g, i32* null) to i32), i32 65537)), [[B22]]
 ; CHECK-NEXT:[[B12:%.*]] = add nuw nsw i32 [[B15]], ashr (i32 65536, i32 or (i32 zext (i1 icmp eq (i32* @g, i32* null) to i32), i32 65537))
-; CHECK-NEXT:[[B8:%.*]] = shl i32 sdiv (i32 or (i32 zext (i1 icmp eq (i32* @g, i32* null) to i32), i32 65537), i32 2147483647), [[B14]]
-; CHECK-NEXT:[[B2:%.*]] = xor i32 [[B12]], [[B8]]
-; CHECK-NEXT:[[B:%.*]] = xor i32 [[B2]], -1
+; CHECK-NEXT:[[B:%.*]] = xor i32 [[B12]], -1
 ; CHECK-NEXT:store i32 [[B]], i32* undef, align 4
 ; CHECK-NEXT:ret void
 ;
Index: llvm/test/Analysis/ScalarEvolution/ptrtoint-constantexpr-loop.ll
===
--- llvm/test/Analysis/ScalarEvolution/ptrtoint-constantexpr-loop.ll
+++ llvm/test/Analysis/ScalarEvolution/ptrtoint-constantexpr-loop.ll
@@ -394,7 +394,7 @@
 ; PTR64_IDX64-NEXT:%ii = sext i32 %i to i64
 ; PTR64_IDX64-NEXT:--> (sext i32 {1,+,1}<%for.body> to i64) U: [-2147483648,2147483648) S: [-2147483648,2147483648) --> (sext i32 (-1 + (trunc i64 (ptrtoint i64 (i32)* @sext_like_noop to i64) to i32)) to i64) U: [-2147483648,2147483648) S: [-2147483648,2147483648)
 ; PTR64_IDX64-NEXT:%div = sdiv i64 5, %ii
-; PTR64_IDX64-NEXT:--> %div U: full-set S: full-set --> sdiv (i64 5, i64 sext (i32 add (i32 ptrtoint (i64 (i32)* @sext_like_noop to i32), i32 -1) to i64)) U: full-set S: full-set
+; PTR64_IDX64-NEXT:--> %div U: full-set S: full-set
 ; PTR64_IDX64-NEXT:%i = phi i32 [ %inc, %for.body ], [ 1, %entry ]
 ; PTR64_IDX64-NEXT:--> {1,+,1}<%for.body> U: [1,0) S: [1,0) Exits: (-1 + (trunc i64 (ptrtoint i64 (i32)* @sext_like_noop to i64) to i32)) LoopDispositions: { %for.body: Computable }
 ; PTR64_IDX64-NEXT:%inc = add nuw i32 %i, 1
@@ -411,7 +411,7 @@
 ; PTR64_IDX32-NEXT:%ii = sext i32 %i to i64
 ; PTR64_IDX32-NEXT:--> (sext i32 {1,+,1}<%for.body> to i64) U: [-2147483648,2147483648) S: [-2147483648,2147483648) --> (sext i32 (-1 + ptrtoint (i64 (i32)* @sext_like_noop to i32)) to i64) U: [-2147483648,2147483648) S: [-2147483648,2147483648)
 ; PTR64_IDX32-NEXT:%div = sdiv i64 5, %ii
-; PTR64_IDX32-NEXT:--> %div U: full-set S: full-set --> sdiv (i64 5, i64 sext (i32 add (i32 ptrtoint (i64 (i32)* @sext_like_noop to i32), i32 -1) to i64)) U: full-set S: full-set
+; PTR64_IDX32-NEXT:--> %div U: full-set S: full-set
 ; PTR64_IDX32-NEXT:%i = phi i32 [ %inc, %for.body ], [ 1, %entry ]
 ; PTR64_IDX32-NEXT:--> {1,+,1}<%for.body> U: [1,0) S: [1,0) Exits: (-1 + ptrtoint (i64 (i32)* @sext_like_noop to i32)) LoopDispositions: { %for.body: Computable }
 ; PTR64_IDX32-NEXT:%inc = add nuw i32 %i, 1
@@ -428,7 +428,7 @@
 ; PTR16_IDX16-NEXT:%ii = sext i32 %i to i64
 ; PTR16_IDX16-NEXT:--> (sext i32 {1,+,1}<%for.body> to i64) U: [-2147483648,2147483648) S: [-2147483648,2147483648) --> (-1 + (zext i16 (ptrtoint i64 (i32)* @sext_like_noop to i16) to 

[PATCH] D128820: [ConstExpr] Don't create div/rem expressions

[Nikita Popov via Phabricator via cfe-commits]

nikic added inline comments.



Comment at: llvm/lib/IR/Constants.cpp:2368-2379
+bool ConstantExpr::isDesirableBinOp(unsigned Opcode) {
+  assert(Instruction::isBinaryOp(Opcode) && "Argument must be binop opcode");
+  switch (Opcode) {
+  case Instruction::UDiv:
+  case Instruction::SDiv:
+  case Instruction::URem:
+  case Instruction::SRem:

nhaehnle wrote:
> Is the plan to successively make more ops undesirable? Perhaps this should be 
> a whitelist instead of a blacklist.
I went with the "Why don't we have both?" approach here and explicitly listed 
both the desirable and undesirable binops. And yes, I plan to successively move 
these until only add and sub are left in the bottom list.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128820

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

[PATCH] D124159: [SimplifyCFG] Thread branches on same condition in more cases (PR54980)

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

I ended up reverting this patch in 
https://github.com/llvm/llvm-project/commit/a4772cbaf0dc717ab6b4639272ca2910897613f0,
 because I reduced another infinite loop 
(https://github.com/llvm/llvm-project/issues/56203) to it as well, which makes 
it the third one. It's probably not possible to reliably prevent infinite 
combine loops in this area with a dominator tree.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124159

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

[PATCH] D124159: [SimplifyCFG] Thread branches on same condition in more cases (PR54980)

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

@nathanchance Thanks for the report. I've applied the obvious fix in 
https://github.com/llvm/llvm-project/commit/20962c1240691d25b21ce425313c81eed0b1b358.
 However, I think that this (and similar limitations relating to critical edge 
splitting) might actually be unnecessary since 
https://github.com/llvm/llvm-project/commit/7a7bba289521e6d4da199565cf72dc9eaed3d671.
 callbr has stricter semantics than indirectbr, and apparently updating 
successors of a callbr //is// supposed to be possible (because the 
blockaddresses used by it must be directly used in the call arguments and thus 
can be updated, while in the indirectbr case they may be passed indirectly).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124159

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

[PATCH] D122471: [IR] Require intrinsic struct return type to be anonymous

[Nikita Popov 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 rG8a72391f609f: [IR] Require intrinsic struct return type to 
be anonymous (authored by nikic).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D122471?vs=418812&id=419058#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122471

Files:
  clang/test/CodeGenCUDA/texture.cu
  llvm/lib/IR/AutoUpgrade.cpp
  llvm/lib/IR/Function.cpp
  llvm/test/Bitcode/intrinsics-struct-upgrade.ll
  llvm/test/Bitcode/intrinsics-struct-upgrade.ll.bc
  llvm/test/CodeGen/X86/2009-04-12-FastIselOverflowCrash.ll
  llvm/test/CodeGen/X86/fast-isel-extract.ll

Index: llvm/test/CodeGen/X86/fast-isel-extract.ll
===
--- llvm/test/CodeGen/X86/fast-isel-extract.ll
+++ llvm/test/CodeGen/X86/fast-isel-extract.ll
@@ -1,7 +1,6 @@
 ; RUN: llc < %s -mtriple x86_64-apple-darwin11 -O0 -fast-isel-abort=1 | FileCheck %s
 
 %struct.x = type { i64, i64 }
-%addovf = type { i32, i1 }
 declare %struct.x @f()
 
 define void @test1(i64*) nounwind ssp {
@@ -28,13 +27,13 @@
 ; CHECK: addq $10, %rdx
 }
 
-declare %addovf @llvm.sadd.with.overflow.i32(i32, i32) nounwind readnone
+declare { i32, i1 } @llvm.sadd.with.overflow.i32(i32, i32) nounwind readnone
 
 define void @test3(i32 %x, i32 %y, i32* %z) {
-  %r = call %addovf @llvm.sadd.with.overflow.i32(i32 %x, i32 %y)
-  %sum = extractvalue %addovf %r, 0
+  %r = call { i32, i1 } @llvm.sadd.with.overflow.i32(i32 %x, i32 %y)
+  %sum = extractvalue { i32, i1 } %r, 0
   %sum3 = mul i32 %sum, 3
-  %bit = extractvalue %addovf %r, 1
+  %bit = extractvalue { i32, i1 } %r, 1
   br i1 %bit, label %then, label %end
   
 then:
Index: llvm/test/CodeGen/X86/2009-04-12-FastIselOverflowCrash.ll
===
--- llvm/test/CodeGen/X86/2009-04-12-FastIselOverflowCrash.ll
+++ llvm/test/CodeGen/X86/2009-04-12-FastIselOverflowCrash.ll
@@ -4,9 +4,8 @@
 ; RUN: llc < %s -O0 -mcpu=x86-64 -mattr=+avx512f | FileCheck %s
 target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128"
 target triple = "x86_64-apple-darwin10"
-	%0 = type { i32, i1 }		; type %0
 
-declare %0 @llvm.sadd.with.overflow.i32(i32, i32) nounwind
+declare { i32, i1 } @llvm.sadd.with.overflow.i32(i32, i32) nounwind
 
 define fastcc i32 @test() nounwind {
 entry:
@@ -16,12 +15,12 @@
 ; CHECK-NEXT:addl $0, [[REG]]
 ; CHECK-NEXT:seto {{%[a-z]+l}}
 ; CHECK: jo LBB0_2
-	%tmp1 = call %0 @llvm.sadd.with.overflow.i32(i32 1, i32 0)
-	%tmp2 = extractvalue %0 %tmp1, 1
+	%tmp1 = call { i32, i1 } @llvm.sadd.with.overflow.i32(i32 1, i32 0)
+	%tmp2 = extractvalue { i32, i1 } %tmp1, 1
 	br i1 %tmp2, label %.backedge, label %BB3
 
 BB3:
-	%tmp4 = extractvalue %0 %tmp1, 0
+	%tmp4 = extractvalue { i32, i1 } %tmp1, 0
 	br label %.backedge
 
 .backedge:
Index: llvm/test/Bitcode/intrinsics-struct-upgrade.ll
===
--- /dev/null
+++ llvm/test/Bitcode/intrinsics-struct-upgrade.ll
@@ -0,0 +1,18 @@
+; RUN: llvm-dis < %s.bc | FileCheck %s
+
+%struct.__neon_int8x8x2_t = type { <8 x i8>, <8 x i8> }
+
+declare %struct.__neon_int8x8x2_t @llvm.aarch64.neon.ld2.v8i8.p0i8(i8*)
+
+; CHECK-LABEL: define %struct.__neon_int8x8x2_t @test_named_struct_return(i8* %A) {
+; CHECK:  %1 = call { <8 x i8>, <8 x i8> } @llvm.aarch64.neon.ld2.v8i8.p0i8(i8* %A)
+; CHECK:  %2 = extractvalue { <8 x i8>, <8 x i8> } %1, 0
+; CHECK:  %3 = insertvalue %struct.__neon_int8x8x2_t poison, <8 x i8> %2, 0
+; CHECK:  %4 = extractvalue { <8 x i8>, <8 x i8> } %1, 1
+; CHECK:  %5 = insertvalue %struct.__neon_int8x8x2_t %3, <8 x i8> %4, 1
+; CHECK:  ret %struct.__neon_int8x8x2_t %5
+
+define %struct.__neon_int8x8x2_t @test_named_struct_return(i8* %A) {
+  %val = call %struct.__neon_int8x8x2_t @llvm.aarch64.neon.ld2.v8i8.p0i8(i8* %A)
+  ret %struct.__neon_int8x8x2_t %val
+}
Index: llvm/lib/IR/Function.cpp
===
--- llvm/lib/IR/Function.cpp
+++ llvm/lib/IR/Function.cpp
@@ -1475,9 +1475,19 @@
   PointerType *PT = dyn_cast(Ty);
   if (!PT || PT->getAddressSpace() != D.Pointer_AddressSpace)
 return true;
-  if (!PT->isOpaque())
+  if (!PT->isOpaque()) {
+/* Manually consume a pointer to empty struct descriptor, which is
+ * used for externref. We don't want to enforce that the struct is
+ * anonymous in this case. (This renders externref intrinsics
+ * non-unique, but this will go away with opaque pointers anyway.) */
+if (Infos.front().Kind == IITDescriptor::Struct &&
+Infos.front().Struct_NumElements == 0) {
+  

[PATCH] D122471: [IR] Require intrinsic struct return type to be anonymous

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

@uabelho You shouldn't need to update intrinsic definitions (though you might 
want to update how you codegen the intrinsics). It sounds like the auto-upgrade 
code is going into an infinite loop in your case, but it's not really obvious 
to me how/why that would happen (or why it would happen only for bitcode but 
not IR).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122471

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

[PATCH] D122471: [IR] Require intrinsic struct return type to be anonymous

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

Oh wait, do I see correctly that your intrinsic returns an overloaded type that 
happens to be a struct, rather than returning a struct defined in the intrinsic 
definition? I hadn't considered that case, and it's possible the auto-upgrade 
code is broken for that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122471

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

[PATCH] D122471: [IR] Require intrinsic struct return type to be anonymous

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

@uabelho Can you please check whether 
https://github.com/llvm/llvm-project/commit/d6887256c2cae1b1b721bd47459be6d86003db6f
 fixes the problem you're seeing?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122471

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

[PATCH] D122789: [compiler-rt] [scudo] Use -mcrc32 on x86 when available

[Nikita Popov via Phabricator via cfe-commits]

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

Not familiar with this code, but the newest version does resolve the build 
failure with GCC, so I guess this is fine.


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

https://reviews.llvm.org/D122789

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

[PATCH] D123034: [OpaquePtrs][Clang] Add -opaque-pointers/-no-opaque-pointers cc1 options

[Nikita Popov via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGd69e9f9d8978: [OpaquePtrs][Clang] Add 
-opaque-pointers/-no-opaque-pointers cc1 options (authored by nikic).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123034

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CodeGenAction.cpp
  clang/test/CodeGen/opaque-pointers-flag.c


Index: clang/test/CodeGen/opaque-pointers-flag.c
===
--- /dev/null
+++ clang/test/CodeGen/opaque-pointers-flag.c
@@ -0,0 +1,27 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang_cc1 -no-opaque-pointers -triple x86_64-unknown-unknown 
-emit-llvm %s -o - | FileCheck %s -check-prefix=TYPED
+// RUN: %clang_cc1 -opaque-pointers -triple x86_64-unknown-unknown -emit-llvm 
%s -o - | FileCheck %s -check-prefix=OPAQUE
+// The current default is typed pointers:
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -emit-llvm %s -o - | 
FileCheck %s -check-prefix=TYPED
+
+// TYPED-LABEL: @test(
+// TYPED-NEXT:  entry:
+// TYPED-NEXT:[[P_ADDR:%.*]] = alloca i32*, align 8
+// TYPED-NEXT:store i32* [[P:%.*]], i32** [[P_ADDR]], align 8
+// TYPED-NEXT:[[TMP0:%.*]] = load i32*, i32** [[P_ADDR]], align 8
+// TYPED-NEXT:[[ARRAYIDX:%.*]] = getelementptr inbounds i32, i32* 
[[TMP0]], i64 1
+// TYPED-NEXT:[[TMP1:%.*]] = load i32, i32* [[ARRAYIDX]], align 4
+// TYPED-NEXT:ret i32 [[TMP1]]
+//
+// OPAQUE-LABEL: @test(
+// OPAQUE-NEXT:  entry:
+// OPAQUE-NEXT:[[P_ADDR:%.*]] = alloca ptr, align 8
+// OPAQUE-NEXT:store ptr [[P:%.*]], ptr [[P_ADDR]], align 8
+// OPAQUE-NEXT:[[TMP0:%.*]] = load ptr, ptr [[P_ADDR]], align 8
+// OPAQUE-NEXT:[[ARRAYIDX:%.*]] = getelementptr inbounds i32, ptr 
[[TMP0]], i64 1
+// OPAQUE-NEXT:[[TMP1:%.*]] = load i32, ptr [[ARRAYIDX]], align 4
+// OPAQUE-NEXT:ret i32 [[TMP1]]
+//
+int test(int *p) {
+  return p[1];
+}
Index: clang/lib/CodeGen/CodeGenAction.cpp
===
--- clang/lib/CodeGen/CodeGenAction.cpp
+++ clang/lib/CodeGen/CodeGenAction.cpp
@@ -983,6 +983,9 @@
   if (BA != Backend_EmitNothing && !OS)
 return nullptr;
 
+  if (CI.getCodeGenOpts().OpaquePointers)
+VMContext->enableOpaquePointers();
+
   // Load bitcode modules to link with, if we need to.
   if (LinkModules.empty())
 for (const CodeGenOptions::BitcodeFileToLink &F :
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -5504,6 +5504,13 @@
   PosFlag,
   NegFlag,
   BothFlags<[], " analyzing function argument and return types for mandatory 
definedness">>;
+defm opaque_pointers : BoolOption<"",
+  "opaque-pointers",
+  CodeGenOpts<"OpaquePointers">,
+  DefaultFalse,
+  PosFlag,
+  NegFlag,
+  BothFlags<[], " opaque pointers">>;
 def discard_value_names : Flag<["-"], "discard-value-names">,
   HelpText<"Discard value names in LLVM IR">,
   MarshallingInfoFlag>;
Index: clang/include/clang/Basic/CodeGenOptions.def
===
--- clang/include/clang/Basic/CodeGenOptions.def
+++ clang/include/clang/Basic/CodeGenOptions.def
@@ -469,6 +469,9 @@
 ENUM_CODEGENOPT(ZeroCallUsedRegs, llvm::ZeroCallUsedRegs::ZeroCallUsedRegsKind,
 5, llvm::ZeroCallUsedRegs::ZeroCallUsedRegsKind::Skip)
 
+/// Whether to use opaque pointers.
+CODEGENOPT(OpaquePointers, 1, 0)
+
 #undef CODEGENOPT
 #undef ENUM_CODEGENOPT
 #undef VALUE_CODEGENOPT


Index: clang/test/CodeGen/opaque-pointers-flag.c
===
--- /dev/null
+++ clang/test/CodeGen/opaque-pointers-flag.c
@@ -0,0 +1,27 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang_cc1 -no-opaque-pointers -triple x86_64-unknown-unknown -emit-llvm %s -o - | FileCheck %s -check-prefix=TYPED
+// RUN: %clang_cc1 -opaque-pointers -triple x86_64-unknown-unknown -emit-llvm %s -o - | FileCheck %s -check-prefix=OPAQUE
+// The current default is typed pointers:
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -emit-llvm %s -o - | FileCheck %s -check-prefix=TYPED
+
+// TYPED-LABEL: @test(
+// TYPED-NEXT:  entry:
+// TYPED-NEXT:[[P_ADDR:%.*]] = alloca i32*, align 8
+// TYPED-NEXT:store i32* [[P:%.*]], i32** [[P_ADDR]], align 8
+// TYPED-NEXT:[[TMP0:%.*]] = load i32*, i32** [[P_ADDR]], align 8
+// TYPED-NEXT:[[ARRAYIDX:%.*]] = getelementptr inbounds i32, i32* [[TMP0]], i64 1
+// TYPED-NEXT:[[TMP1:%.*]] = load i32, i32* [[ARRAYIDX]], align 4
+// TYPED-NEXT:ret i32 [[TMP1]]
+//
+// OPAQUE-LABE

[PATCH] D123126: [cmake] Remove LLVM_ENABLE_NEW_PASS_MANAGER cmake option

[Nikita Popov 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 rGed4e6e03981a: [cmake] Remove LLVM_ENABLE_NEW_PASS_MANAGER 
cmake option (authored by nikic).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D123126?vs=420484&id=420730#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123126

Files:
  clang/include/clang/Driver/Options.td
  clang/test/CMakeLists.txt
  clang/test/lit.cfg.py
  clang/test/lit.site.cfg.py.in
  clang/unittests/Frontend/CompilerInvocationTest.cpp
  lld/COFF/Driver.cpp
  lld/ELF/Driver.cpp
  lld/MachO/Config.h
  lld/MachO/Driver.cpp
  lld/wasm/Driver.cpp
  llvm/CMakeLists.txt
  llvm/cmake/modules/LLVMConfig.cmake.in
  llvm/docs/NewPassManager.rst
  llvm/include/llvm/Config/llvm-config.h.cmake
  llvm/include/llvm/LTO/Config.h
  llvm/include/llvm/LTO/legacy/ThinLTOCodeGenerator.h
  llvm/tools/gold/gold-plugin.cpp
  llvm/tools/llvm-lto/llvm-lto.cpp
  llvm/tools/llvm-lto2/llvm-lto2.cpp
  llvm/tools/opt/opt.cpp
  llvm/utils/gn/secondary/clang/test/BUILD.gn
  llvm/utils/gn/secondary/llvm/include/llvm/Config/BUILD.gn
  utils/bazel/llvm-project-overlay/llvm/include/llvm/Config/llvm-config.h
  utils/bazel/llvm_configs/llvm-config.h.cmake

Index: utils/bazel/llvm_configs/llvm-config.h.cmake
===
--- utils/bazel/llvm_configs/llvm-config.h.cmake
+++ utils/bazel/llvm_configs/llvm-config.h.cmake
@@ -97,9 +97,6 @@
 /* Define to 1 if you have the  header file. */
 #cmakedefine HAVE_SYSEXITS_H ${HAVE_SYSEXITS_H}
 
-/* Define to 1 to enable the experimental new pass manager by default */
-#cmakedefine01 LLVM_ENABLE_NEW_PASS_MANAGER
-
 /* Define if the xar_open() function is supported on this platform. */
 #cmakedefine LLVM_HAVE_LIBXAR ${LLVM_HAVE_LIBXAR}
 
Index: utils/bazel/llvm-project-overlay/llvm/include/llvm/Config/llvm-config.h
===
--- utils/bazel/llvm-project-overlay/llvm/include/llvm/Config/llvm-config.h
+++ utils/bazel/llvm-project-overlay/llvm/include/llvm/Config/llvm-config.h
@@ -105,9 +105,6 @@
 /* Define to 1 if you have the  header file. */
 /* HAVE_SYSEXITS_H defined in Bazel */
 
-/* Define to 1 to enable the experimental new pass manager by default */
-#define LLVM_ENABLE_NEW_PASS_MANAGER 0
-
 /* Define if the xar_open() function is supported this platform. */
 /* #undef HAVE_LIBXAR */
 
Index: llvm/utils/gn/secondary/llvm/include/llvm/Config/BUILD.gn
===
--- llvm/utils/gn/secondary/llvm/include/llvm/Config/BUILD.gn
+++ llvm/utils/gn/secondary/llvm/include/llvm/Config/BUILD.gn
@@ -335,7 +335,6 @@
 "LLVM_BUILD_SHARED_LIBS=",
 "LLVM_DEFAULT_TARGET_TRIPLE=$llvm_target_triple",
 "LLVM_ENABLE_DUMP=",
-"LLVM_ENABLE_NEW_PASS_MANAGER=1",
 "LLVM_FORCE_ENABLE_STATS=",
 "LLVM_FORCE_USE_OLD_TOOLCHAIN=",
 "LLVM_HAS_ATOMICS=1",
Index: llvm/utils/gn/secondary/clang/test/BUILD.gn
===
--- llvm/utils/gn/secondary/clang/test/BUILD.gn
+++ llvm/utils/gn/secondary/clang/test/BUILD.gn
@@ -60,7 +60,6 @@
 "CMAKE_CXX_COMPILER=c++",
 "CMAKE_C_COMPILER=cc",
 "ENABLE_BACKTRACES=1",
-"LLVM_ENABLE_NEW_PASS_MANAGER=1",
 "LLVM_EXTERNAL_LIT=",
 "LLVM_HOST_TRIPLE=$llvm_current_triple",
 "LLVM_LIT_TOOLS_DIR=",  # Intentionally empty, matches cmake build.
Index: llvm/tools/opt/opt.cpp
===
--- llvm/tools/opt/opt.cpp
+++ llvm/tools/opt/opt.cpp
@@ -75,7 +75,7 @@
 cl::desc("Enable the new pass manager, translating "
  "'opt -foo' to 'opt -passes=foo'. This is strictly for the new PM "
  "migration, use '-passes=' when possible."),
-cl::init(LLVM_ENABLE_NEW_PASS_MANAGER));
+cl::init(true));
 
 // This flag specifies a textual description of the optimization pass pipeline
 // to run over the module. This flag switches opt to use the new pass manager
Index: llvm/tools/llvm-lto2/llvm-lto2.cpp
===
--- llvm/tools/llvm-lto2/llvm-lto2.cpp
+++ llvm/tools/llvm-lto2/llvm-lto2.cpp
@@ -146,7 +146,7 @@
 static cl::opt
 UseNewPM("use-new-pm",
  cl::desc("Run LTO passes using the new pass manager"),
- cl::init(LLVM_ENABLE_NEW_PASS_MANAGER), cl::Hidden);
+ cl::init(true), cl::Hidden);
 
 static cl::opt
 DebugPassManager("debug-pass-manager", cl::init(false), cl::Hidden,
Index: llvm/tools/llvm-lto/llvm-lto.cpp
===
--- llvm/tools/llvm-lto/llvm-lto.cpp
+++ llvm/tools/llvm-lto/llvm-lto.cpp
@@ -256,9 +256,10 @@
 cl::desc("Inst

[PATCH] D130268: [NFC] Add SmallVector constructor to allow creation of SmallVector from ArrayRef of items convertible to type T

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

I think my only concern with this change is that it will also allow some 
implicit ArrayRef constructors. For example, this will permit creating a 
SmallVector from `std::array`, `std::vector`, or just `T` -- but only if 
`ArrayRef` is in scope. This seems somewhat dangerous.

I'm not sure if C++ provides any good way to avoid that, short of explicitly 
marking certain constructors as deleted?

I'm wondering if it might not be better to make this a fully generic overload 
that accepts any range (i.e., anything with begin() and end()). Paradoxically, 
this will likely be less permissive in practice than having explicit 
iterator_range and ArrayRef overloads, because it allows less implicit 
conversions.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130268

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

[PATCH] D129954: [CodeGen][inlineasm] assume the flag output of inline asm is boolean value

[Nikita Popov via Phabricator via cfe-commits]

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

LGTM. After some further consideration, implementing this properly in LLVM 
would probably take more effort than is worthwhile (especially as this is 
target-specific functionality, so we'd actually have to expose TTI queries for 
this, etc.)




Comment at: clang/lib/CodeGen/CGStmt.cpp:2734
+  llvm::Value *IsBooleanValue =
+  Builder.CreateCmp(llvm::CmpInst::ICMP_ULE, Tmp, OneVal);
+  llvm::Function *FnAssume = CGM.getIntrinsic(llvm::Intrinsic::assume);

The canonical form of this is `< 2` rather than `<= 1`.



Comment at: clang/test/CodeGen/inline-asm-x86-flag-output.c:378
+
+int test_assume_boolean_flag(long nr, volatile long *addr) {
+  //CHECK-LABEL: @test_assume_boolean_flag

You might want to check that we're doing the right thing if there are multiple 
output constraints (via extractvalue).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129954

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

[PATCH] D130268: [NFC] Add SmallVector constructor to allow creation of SmallVector from ArrayRef of items convertible to type T

[Nikita Popov via Phabricator via cfe-commits]

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

LGTM

In D130268#3686811 , @yurai007 wrote:

> In D130268#3684244 , @nikic wrote:
>
>> I think my only concern with this change is that it will also allow some 
>> implicit ArrayRef constructors. For example, this will permit creating a 
>> SmallVector from `std::array`, `std::vector`, or just `T` -- but only if 
>> `ArrayRef` is in scope. This seems somewhat dangerous.
>
> Maybe I'm missing something, but is it right? It appears that only one 
> implicit conversion in constructor is allowed: 
> https://stackoverflow.com/questions/63320366/double-implicit-conversion-in-c
> I think going from vector/array to SmallVector is ill-formed unless we 
> explicitly create temporary ArrayRef in-between: 
> https://godbolt.org/z/Geqbajf1x

You're right... Everything's good then.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130268

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

[PATCH] D130766: [SPIR-V] Disable opaque pointers in relese 15

[Nikita Popov via Phabricator via cfe-commits]

nikic added reviewers: jcranmer-intel, opaque-pointers.
nikic added a comment.

LG from my side, as a temporary workaround.


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

https://reviews.llvm.org/D130766

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

[PATCH] D125291: Introduce @llvm.threadlocal.address intrinsic to access TLS variable

[Nikita Popov via Phabricator via cfe-commits]

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

LG. Now that LLVM 15 has branched, I think it is safe to land this, and there 
will be enough time before LLVM 16 to convert it to the token variant.




Comment at: llvm/docs/LangRef.rst:24546
+
+The first argument is a pointer, which refers to a thread local variable.
+

I'd replace variable -> global here.


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

https://reviews.llvm.org/D125291

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

[PATCH] D130689: [LLVM] Update C++ standard to 17

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

In D130689#3690258 , @thieta wrote:

> In D130689#3689157 , @thakis wrote:
>
>> Is it expected and intentional that this increases the mac deployment target 
>> to 10.12?
>
> I wasn't aware of that - but I think it's expected since the check in RWMutex 
> checks for the C++ standard and doesn't care about the deployment target for 
> macOS. It seems pretty easy to change, but I wonder if that matters? 10.12 
> was released in 2016 so it's pretty old and this wouldn't affect most users 
> of LLVM.
>
> My gut feeling say that we should be fine with requiring 10.12 and if that 
> becomes a big problem during the development phase someone could propose a 
> patch to improve the check in RWMutex.
>
> But in that case we should probably have a check for the deployment target as 
> part of the cmake config and error if CXX_STANDARD > 17 and 
> OSX_DEPLOYMENT_TARGET < 10.12.

Given 
https://github.com/llvm/llvm-project/blob/2bb7c54621f31a957302a4deb3d25b752acb07bd/llvm/include/llvm/Support/RWMutex.h#L22-L27,
 it seems like this is supposed to be supported. This is probably just a matter 
of moving the shared_mutex use behind the LLVM_USE_RW_MUTEX_IMPL guard?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130689

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

[PATCH] D130268: [NFC] Add SmallVector constructor to allow creation of SmallVector from ArrayRef of items convertible to type T

[Nikita Popov via Phabricator via cfe-commits]

nikic accepted this revision.
nikic added a comment.

Still LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130268

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

[PATCH] D130754: [X86] Support ``-mindirect-branch-cs-prefix`` for call and jmp to indirect thunk

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

This change caused a significant compile-time regression for `O0` builds (about 
1%): 
http://llvm-compile-time-tracker.com/compare.php?from=45bae1be90472c696f6ba3bb4f8fabee76040fa9&to=6f867f9102838ebe314c1f3661fdf95700386e5a&stat=instructions

At a guess, fetching a module flag for every single instruction is slow?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130754

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

[PATCH] D131282: [mlir] fix `add_tablegen()` macro to allow installing mlir-pdll

[Nikita Popov via Phabricator via cfe-commits]

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

LGTM




Comment at: llvm/cmake/modules/TableGen.cmake:147
+  cmake_parse_arguments(ADD_TABLEGEN "${options}" "${oneValueArgs}"
+"${multiValueArgs}" ${ARGN})
+

I think it would be fine to write this as just 
`cmake_parse_arguments(ADD_TABLEGEN "" "OPTIONS" "" ${ARGN})`, but don't feel 
strongly about that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131282

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

[PATCH] D131351: [C] Default implicit function pointer conversions diagnostic to be an error

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

This seems to break the test-suite build:

  FAILED: CTMark/ClamAV/CMakeFiles/clamscan.dir/libclamav_readdb.c.o 
  /root/llvm-compile-time-tracker/llvm-test-suite-build/tools/timeit --summary 
CTMark/ClamAV/CMakeFiles/clamscan.dir/libclamav_readdb.c.o.time 
/root/llvm-compile-time-tracker/llvm-project-build/bin/clang -DNDEBUG  
-fexperimental-new-pass-manager -O0 -g   -w -Werror=date-time -DHAVE_CONFIG_H 
-I/root/llvm-compile-time-tracker/llvm-test-suite/CTMark/ClamAV 
-I/root/llvm-compile-time-tracker/llvm-test-suite/CTMark/ClamAV/zlib 
-DDONT_LOCK_DBDIRS -DC_LINUX -DFPU_WORDS_BIGENDIAN=0 -DWORDS_BIGENDIAN=0 -MD 
-MT CTMark/ClamAV/CMakeFiles/clamscan.dir/libclamav_readdb.c.o -MF 
CTMark/ClamAV/CMakeFiles/clamscan.dir/libclamav_readdb.c.o.d -o 
CTMark/ClamAV/CMakeFiles/clamscan.dir/libclamav_readdb.c.o   -c 
/root/llvm-compile-time-tracker/llvm-test-suite/CTMark/ClamAV/libclamav_readdb.c
  
/root/llvm-compile-time-tracker/llvm-test-suite/CTMark/ClamAV/libclamav_readdb.c:1145:49:
 error: incompatible function pointer types passing 'int (const struct dirent 
*, const struct dirent *)' to parameter of type '__compar_fn_t' (aka 'int 
(*)(const void *, const void *)') [-Wincompatible-function-pointer-types]
  qsort(dents, ndents, sizeof(struct dirent), dirent_compare);
  ^~
  /usr/include/stdlib.h:831:20: note: passing argument to parameter '__compar' 
here
 __compar_fn_t __compar) __nonnull ((1, 4));
   ^
  1 error generated.

Is it intentional that this generates an error for benign differences (in 
pointer types only)?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131351

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

[PATCH] D106184: [BPF] Use elementtype attribute for preserve.array/struct.index intrinsics

[Nikita Popov via Phabricator via cfe-commits]

nikic added inline comments.



Comment at: llvm/lib/Target/BPF/BPFAbstractMemberAccess.cpp:303
 CInfo.RecordAlignment =
 DL->getABITypeAlign(CInfo.Base->getType()->getPointerElementType());
 return true;

I noticed too late that this intrinsic also uses the element type to get the 
alignment. I'll have to follow up with the same change for this intrinsic.

Though I'm not completely sure if this is actually used, because no tests fail 
if I replace this with dummy values like 1 or 128.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106184

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

[PATCH] D106184: [BPF] Use elementtype attribute for preserve.array/struct.index intrinsics

[Nikita Popov via Phabricator via cfe-commits]

nikic closed this revision.
nikic added a comment.

Landed as 
https://github.com/llvm/llvm-project/commit/be5af50e7d028849bf2fab5f4b0f2ad36ae56e11,
 missed the "Differential Revision" tag.

For the record, the problem with the autoupgrade test was PEBKAC: The textual 
diff that gets uploaded to Phabricator didn't include the contents of the 
binary bitcode file, and apparently LLVM happily interprets an empty bitcode 
file as an empty module.


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

https://reviews.llvm.org/D106184

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

[PATCH] D106401: [CUDA, MemCpyOpt] Add a flag to force-enable memcpyopt and use it for CUDA.

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

Would the variant of the original patch at D106769 
 be sufficient for your purposes? Or are you 
also interested in the optimizations that introduce new memset/memcpy?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106401

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

[PATCH] D121135: [NFC][Clang][OpaquePtr] Remove calls to Address::deprecated in a couple more files

[Nikita Popov via Phabricator via cfe-commits]

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

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121135

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

[PATCH] D120527: [OpaquePtr][AArch64] Use elementtype on ldxr/stxr

[Nikita Popov via Phabricator via cfe-commits]

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

LGTM. You probably want to add these intrinsics to the auto-upgrade code in 
`BitcodeReader::propagateAttributeTypes()` as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120527

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

[PATCH] D120527: [OpaquePtr][AArch64] Use elementtype on ldxr/stxr

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

@aeubanks Do you plan to take care of the corresponding arm intrinsics as well?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120527

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

[PATCH] D121847: [OpaquePtr][ARM] Use elementtype on ldrex/ldaex/stlex/strex

[Nikita Popov via Phabricator via cfe-commits]

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

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121847

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

[PATCH] D122046: [clang] Remove Address::deprecated from MveEmitter

[Nikita Popov via Phabricator via cfe-commits]

nikic added inline comments.



Comment at: clang/utils/TableGen/MveEmitter.cpp:1197
+const Type *Ty = nullptr;
+if (auto *DI = dyn_cast(D->getArg(0))->getOperator())
+  if (auto *PTy = dyn_cast(getType(DI, Param)))

Should be either `cast` or check for nullptr before dereferencing?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122046

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

[PATCH] D122199: [NFC][Clang][OpaquePtr] Remove calls to Address::deprecated in TargetInfo.cpp

[Nikita Popov via Phabricator via cfe-commits]

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

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122199

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

[PATCH] D115924: [ConstantFolding] Unify handling of load from uniform value

[Nikita Popov via Phabricator via cfe-commits]

nikic added inline comments.



Comment at: llvm/lib/Analysis/ConstantFolding.cpp:722
+  (Ty->isIntOrIntVectorTy() || Ty->isFPOrFPVectorTy()))
+return Constant::getAllOnesValue(Ty);
+  return nullptr;

cameron.mcinally wrote:
> Sorry for the late comment, but is this legal to do if the src and dest types 
> are different sizes? E.g.:
> 
> ```
> %xxx_cast = bitcast i8* %xxx to i1*
> store i1 true, i1* %xxx_cast
> %yyy = load i8, i8* %xxx
> ```
> 
> In this case, we'll be turning an i1 -1 into an i8 -1, which changes bits.
This code assumes that the loaded type is either smaller or that loading a 
larger type fills in the remaining bits with poison, so we can use any value 
for them. The caller is responsible for doing a type size check if necessary.

However, I don't believe that non-byte-sized types were really considered 
either here or in other parts of the constant load folding code. In that case 
the type store sizes are the same, but the type sizes differ.

Now, as to whether this behavior is actually incorrect, LangRef has the 
following to say on non-byte-sized memory accesses:

> When writing a value of a type like i20 with a size that is not an integral 
> number of bytes, it is unspecified what happens to the extra bits that do not 
> belong to the type, but they will typically be overwritten.

> When loading a value of a type like i20 with a size that is not an integral 
> number of bytes, the result is undefined if the value was not originally 
> written using a store of the same type.

Based on a strict reading, I believe the store of i1 and load of i8 would 
result in the remaining bits having an unspecified, but generally non-poison 
value. The reverse would be UB (which really doesn't make sense to me -- it 
would be great if we could rework this to be more well-defined.)

So, yeah, I'd say this is a bug. I'll take a look.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115924

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

[PATCH] D123122: [OpaquePtr][Clang] Add CLANG_ENABLE_OPAQUE_POINTERS cmake option

[Nikita Popov via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG5390606aa963: [OpaquePtr][Clang] Add 
CLANG_ENABLE_OPAQUE_POINTERS cmake option (authored by nikic).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D123122?vs=420738&id=421120#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123122

Files:
  clang/CMakeLists.txt
  clang/include/clang/Config/config.h.cmake
  clang/include/clang/Driver/Options.td


Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -5507,7 +5507,7 @@
 defm opaque_pointers : BoolOption<"",
   "opaque-pointers",
   CodeGenOpts<"OpaquePointers">,
-  DefaultFalse,
+  Default<"CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL">,
   PosFlag,
   NegFlag,
   BothFlags<[], " opaque pointers">>;
Index: clang/include/clang/Config/config.h.cmake
===
--- clang/include/clang/Config/config.h.cmake
+++ clang/include/clang/Config/config.h.cmake
@@ -89,4 +89,7 @@
 /* Spawn a new process clang.exe for the CC1 tool invocation, when necessary */
 #cmakedefine01 CLANG_SPAWN_CC1
 
+/* Whether to enable opaque pointers by default */
+#cmakedefine01 CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL
+
 #endif
Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -247,6 +247,17 @@
 
 option(CLANG_DEFAULT_PIE_ON_LINUX "Default to -fPIE and -pie on linux-gnu" ON)
 
+# Manually handle default so we can change the meaning of a cached default.
+set(CLANG_ENABLE_OPAQUE_POINTERS "DEFAULT" CACHE STRING
+"Enable opaque pointers by default")
+if(CLANG_ENABLE_OPAQUE_POINTERS STREQUAL "DEFAULT")
+  set(CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL OFF)
+elseif(CLANG_ENABLE_OPAQUE_POINTERS)
+  set(CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL ON)
+else()
+  set(CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL OFF)
+endif()
+
 # TODO: verify the values against LangStandards.def?
 set(CLANG_DEFAULT_STD_C "" CACHE STRING
   "Default standard to use for C/ObjC code (IDENT from LangStandards.def, 
empty for platform default)")


Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -5507,7 +5507,7 @@
 defm opaque_pointers : BoolOption<"",
   "opaque-pointers",
   CodeGenOpts<"OpaquePointers">,
-  DefaultFalse,
+  Default<"CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL">,
   PosFlag,
   NegFlag,
   BothFlags<[], " opaque pointers">>;
Index: clang/include/clang/Config/config.h.cmake
===
--- clang/include/clang/Config/config.h.cmake
+++ clang/include/clang/Config/config.h.cmake
@@ -89,4 +89,7 @@
 /* Spawn a new process clang.exe for the CC1 tool invocation, when necessary */
 #cmakedefine01 CLANG_SPAWN_CC1
 
+/* Whether to enable opaque pointers by default */
+#cmakedefine01 CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL
+
 #endif
Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -247,6 +247,17 @@
 
 option(CLANG_DEFAULT_PIE_ON_LINUX "Default to -fPIE and -pie on linux-gnu" ON)
 
+# Manually handle default so we can change the meaning of a cached default.
+set(CLANG_ENABLE_OPAQUE_POINTERS "DEFAULT" CACHE STRING
+"Enable opaque pointers by default")
+if(CLANG_ENABLE_OPAQUE_POINTERS STREQUAL "DEFAULT")
+  set(CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL OFF)
+elseif(CLANG_ENABLE_OPAQUE_POINTERS)
+  set(CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL ON)
+else()
+  set(CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL OFF)
+endif()
+
 # TODO: verify the values against LangStandards.def?
 set(CLANG_DEFAULT_STD_C "" CACHE STRING
   "Default standard to use for C/ObjC code (IDENT from LangStandards.def, empty for platform default)")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D120305: [Driver] Default CLANG_DEFAULT_PIE_ON_LINUX to ON

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

Looks like this causes a relocation failure on this buildbot: 
https://lab.llvm.org/buildbot/#/builders/169/builds/7311

  ld.lld: error: relocation R_MIPS_64 cannot be used against local symbol; 
recompile with -fPIC
  >>> defined in ScudoUnitTestsObjects.wrappers_cpp_test.cpp.mips64.o
  >>> referenced by wrappers_cpp_test.cpp
  >>>   
ScudoUnitTestsObjects.wrappers_cpp_test.cpp.mips64.o:(.eh_frame+0x15A39)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120305

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

[PATCH] D123115: [OpaquePtrs][Clang] Add -no-opaque-pointers to tests

[Nikita Popov 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 rG532dc62b9075: [OpaquePtrs][Clang] Add -no-opaque-pointers to 
tests (NFC) (authored by nikic).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D123115?vs=420439&id=421146#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123115

Files:
  clang/test/CXX/drs/dr158.cpp
  clang/test/CXX/except/except.spec/p14-ir.cpp
  clang/test/CXX/except/except.spec/p9-dynamic.cpp
  clang/test/CXX/except/except.spec/p9-noexcept.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.lambda/blocks-irgen.mm
  clang/test/CXX/expr/p10-0x.cpp
  clang/test/CXX/special/class.copy/p15-inclass.cpp
  clang/test/CodeGen/2004-02-13-BuiltinFrameReturnAddress.c
  clang/test/CodeGen/2005-01-02-ConstantInits.c
  clang/test/CodeGen/2005-12-04-AttributeUsed.c
  clang/test/CodeGen/2006-01-13-StackSave.c
  clang/test/CodeGen/2006-05-19-SingleEltReturn.c
  clang/test/CodeGen/2007-03-27-VarLengthArray.c
  clang/test/CodeGen/2007-05-16-EmptyStruct.c
  clang/test/CodeGen/2007-11-07-CopyAggregateAlign.c
  clang/test/CodeGen/2007-11-07-ZeroAggregateAlign.c
  clang/test/CodeGen/2008-03-05-syncPtr.c
  clang/test/CodeGen/2008-08-07-AlignPadding1.c
  clang/test/CodeGen/2009-02-13-zerosize-union-field.c
  clang/test/CodeGen/2010-01-13-MemBarrier.c
  clang/test/CodeGen/2010-05-26-AsmSideEffect.c
  clang/test/CodeGen/2010-07-14-overconservative-align.c
  clang/test/CodeGen/2010-07-14-ref-off-end.c
  clang/test/CodeGen/2011-03-31-ArrayRefFolding.c
  clang/test/CodeGen/24-bit.c
  clang/test/CodeGen/64bit-swiftcall.c
  clang/test/CodeGen/Atomics.c
  clang/test/CodeGen/Nontemporal.cpp
  clang/test/CodeGen/PowerPC/aix-alignment.c
  clang/test/CodeGen/PowerPC/aix-altivec-vaargs.c
  clang/test/CodeGen/PowerPC/aix-altivec.c
  clang/test/CodeGen/PowerPC/aix-constructor-attribute.c
  clang/test/CodeGen/PowerPC/aix-destructor-attribute.c
  clang/test/CodeGen/PowerPC/aix-ignore-xcoff-visibility.cpp
  clang/test/CodeGen/PowerPC/aix-init-priority-attribute.cpp
  clang/test/CodeGen/PowerPC/aix-struct-arg.c
  clang/test/CodeGen/PowerPC/aix-vaargs.c
  clang/test/CodeGen/PowerPC/aix32-complex-varargs.c
  clang/test/CodeGen/PowerPC/bool_test.c
  clang/test/CodeGen/PowerPC/builtins-ppc-32bit-vec-ll.c
  clang/test/CodeGen/PowerPC/builtins-ppc-altivec.c
  clang/test/CodeGen/PowerPC/builtins-ppc-build-pair-mma.c
  clang/test/CodeGen/PowerPC/builtins-ppc-cache.c
  clang/test/CodeGen/PowerPC/builtins-ppc-fastmath.c
  clang/test/CodeGen/PowerPC/builtins-ppc-ld-st-rmb.c
  clang/test/CodeGen/PowerPC/builtins-ppc-p10vector.c
  clang/test/CodeGen/PowerPC/builtins-ppc-p9vector.c
  clang/test/CodeGen/PowerPC/builtins-ppc-pair-mma.c
  clang/test/CodeGen/PowerPC/builtins-ppc-quadword.c
  clang/test/CodeGen/PowerPC/builtins-ppc-vsx.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xl-xst.c
  
clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-LoadReseve-StoreCond-64bit-only.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-LoadReseve-StoreCond.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-cas.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-cmplx.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-compare.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-fetch.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-fp.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-load-store-reversed.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-macros.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-math.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-prefetch.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-pwr8.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-rotate.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-stfiw.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-swdiv.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-swdiv_nochk.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-sync.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat.c
  clang/test/CodeGen/PowerPC/ignore-exceptions.cpp
  clang/test/CodeGen/PowerPC/powerpc-c99complex.c
  clang/test/CodeGen/PowerPC/ppc-aggregate-abi.cpp
  clang/test/CodeGen/PowerPC/ppc-mma-types.c
  clang/test/CodeGen/PowerPC/ppc-varargs-struct.c
  clang/test/CodeGen/PowerPC/ppc32-and-aix-struct-return.c
  clang/test/CodeGen/PowerPC/ppc32-dwarf.c
  clang/test/CodeGen/PowerPC/ppc64-align-struct.c
  clang/test/CodeGen/PowerPC/ppc64-complex-parms.c
  clang/test/CodeGen/PowerPC/ppc64-dwarf.c
  clang/test/CodeGen/PowerPC/ppc64-elf-abi.c
  clang/test/CodeGen/PowerPC/ppc64-f128-builtins.c
  clang/test/CodeGen/PowerPC/ppc64-inline-asm.c
  clang/test/CodeGen/PowerPC/ppc64-soft-float.c
  clang/test/CodeGen/PowerPC/ppc64-struct-onefloat.c
  clang/test/CodeGen/PowerPC/ppc64-varargs-complex.c
  clang/test/CodeGen/PowerPC/ppc64-vector

[PATCH] D115924: [ConstantFolding] Unify handling of load from uniform value

[Nikita Popov via Phabricator via cfe-commits]

nikic added inline comments.



Comment at: llvm/lib/Analysis/ConstantFolding.cpp:722
+  (Ty->isIntOrIntVectorTy() || Ty->isFPOrFPVectorTy()))
+return Constant::getAllOnesValue(Ty);
+  return nullptr;

cameron.mcinally wrote:
> nikic wrote:
> > cameron.mcinally wrote:
> > > Sorry for the late comment, but is this legal to do if the src and dest 
> > > types are different sizes? E.g.:
> > > 
> > > ```
> > > %xxx_cast = bitcast i8* %xxx to i1*
> > > store i1 true, i1* %xxx_cast
> > > %yyy = load i8, i8* %xxx
> > > ```
> > > 
> > > In this case, we'll be turning an i1 -1 into an i8 -1, which changes bits.
> > This code assumes that the loaded type is either smaller or that loading a 
> > larger type fills in the remaining bits with poison, so we can use any 
> > value for them. The caller is responsible for doing a type size check if 
> > necessary.
> > 
> > However, I don't believe that non-byte-sized types were really considered 
> > either here or in other parts of the constant load folding code. In that 
> > case the type store sizes are the same, but the type sizes differ.
> > 
> > Now, as to whether this behavior is actually incorrect, LangRef has the 
> > following to say on non-byte-sized memory accesses:
> > 
> > > When writing a value of a type like i20 with a size that is not an 
> > > integral number of bytes, it is unspecified what happens to the extra 
> > > bits that do not belong to the type, but they will typically be 
> > > overwritten.
> > 
> > > When loading a value of a type like i20 with a size that is not an 
> > > integral number of bytes, the result is undefined if the value was not 
> > > originally written using a store of the same type.
> > 
> > Based on a strict reading, I believe the store of i1 and load of i8 would 
> > result in the remaining bits having an unspecified, but generally 
> > non-poison value. The reverse would be UB (which really doesn't make sense 
> > to me -- it would be great if we could rework this to be more well-defined.)
> > 
> > So, yeah, I'd say this is a bug. I'll take a look.
> Thanks, Nikita.
> 
> Looking at the LangRef language, I suspect that you're correct here:
> 
> ```
> Based on a strict reading, I believe the store of i1 and load of i8 would 
> result in the remaining bits having an unspecified, but generally non-poison 
> value. 
> ```
> 
> Requiring the IR producer to maintain those unspecified bits is an acceptable 
> answer. ;)
> 
> I wish LangRef took the responsibility of maintaining the unspecified i1/i4 
> bits off of the IR producer, since they're so common in predication, but I 
> also understand the access instruction limitations as well. It's an 
> unfortunate situation.
I've landed a partial fix in 
https://github.com/llvm/llvm-project/commit/930a68765dff96927d706d258ef0c2ad9c7ec2ab,
 because this was checking the wrong type sizes.

I plan to also add handling for this in the constant folding code though, to 
also fix this variant of the problem: 
https://github.com/llvm/llvm-project/commit/659871cede9e3475c5de986ba4cace58e70f4801#diff-cc91356612b63dff2481358f87d5da7e98d7bbf8fc65c80e55d55c20b1dba462


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115924

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

[PATCH] D123376: [llvm-lto] Remove support for legacy pass manager

[Nikita Popov 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 rG2121dc5b158b: [llvm-lto] Remove support for legacy pass 
manager (authored by nikic).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123376

Files:
  clang/test/Driver/memtag_lto.c
  llvm/include/llvm/LTO/legacy/LTOCodeGenerator.h
  llvm/include/llvm/LTO/legacy/ThinLTOCodeGenerator.h
  llvm/test/Analysis/StackSafetyAnalysis/ipa-alias.ll
  llvm/test/Analysis/StackSafetyAnalysis/ipa.ll
  llvm/test/Feature/load_extension.ll
  llvm/test/LTO/Resolution/X86/load-sample-prof-icp.ll
  llvm/test/LTO/Resolution/X86/load-sample-prof-lto.ll
  llvm/test/LTO/X86/diagnostic-handler-remarks.ll
  llvm/test/LTO/X86/disable-verify.ll
  llvm/test/LTO/X86/tailcallelim.ll
  llvm/test/LTO/X86/tli-nobuiltin.ll
  llvm/test/Other/X86/lto-hot-cold-split.ll
  llvm/test/ThinLTO/X86/cfi-devirt.ll
  llvm/test/ThinLTO/X86/cfi-unsat.ll
  llvm/test/ThinLTO/X86/cfi.ll
  llvm/test/ThinLTO/X86/devirt-after-icp.ll
  llvm/test/ThinLTO/X86/devirt.ll
  llvm/test/ThinLTO/X86/devirt2.ll
  llvm/test/ThinLTO/X86/devirt_check.ll
  llvm/test/ThinLTO/X86/devirt_external_comdat_same_guid.ll
  llvm/test/ThinLTO/X86/devirt_local_same_guid.ll
  llvm/test/ThinLTO/X86/devirt_promote.ll
  llvm/test/ThinLTO/X86/devirt_vcall_vis_hidden.ll
  llvm/test/ThinLTO/X86/devirt_vcall_vis_public.ll
  llvm/test/ThinLTO/X86/diagnostic-handler-remarks-with-hotness.ll
  llvm/test/ThinLTO/X86/diagnostic-handler-remarks.ll
  llvm/test/ThinLTO/X86/newpm-basic.ll
  llvm/test/ThinLTO/X86/nodevirt-nonpromoted-typeid.ll
  llvm/test/ThinLTO/X86/printer.ll
  llvm/test/tools/llvm-lto2/X86/pipeline.ll
  llvm/test/tools/llvm-lto2/X86/slp-vectorize-pm.ll
  llvm/tools/llvm-lto/llvm-lto.cpp
  llvm/tools/llvm-lto2/llvm-lto2.cpp

Index: llvm/tools/llvm-lto2/llvm-lto2.cpp
===
--- llvm/tools/llvm-lto2/llvm-lto2.cpp
+++ llvm/tools/llvm-lto2/llvm-lto2.cpp
@@ -143,11 +143,6 @@
  cl::desc("Run PGO context sensitive IR instrumentation"),
  cl::init(false), cl::Hidden);
 
-static cl::opt
-UseNewPM("use-new-pm",
- cl::desc("Run LTO passes using the new pass manager"),
- cl::init(true), cl::Hidden);
-
 static cl::opt
 DebugPassManager("debug-pass-manager", cl::init(false), cl::Hidden,
  cl::desc("Print pass management debugging information"));
@@ -267,7 +262,6 @@
   Conf.AAPipeline = AAPipeline;
 
   Conf.OptLevel = OptLevel - '0';
-  Conf.UseNewPM = UseNewPM;
   Conf.Freestanding = EnableFreestanding;
   for (auto &PluginFN : PassPlugins)
 Conf.PassPlugins.push_back(PluginFN);
Index: llvm/tools/llvm-lto/llvm-lto.cpp
===
--- llvm/tools/llvm-lto/llvm-lto.cpp
+++ llvm/tools/llvm-lto/llvm-lto.cpp
@@ -256,11 +256,6 @@
 cl::desc("Instead of running LTO, print the mach-o cpu in each IR file"),
 cl::cat(LTOCategory));
 
-static cl::opt
-UseNewPM("use-new-pm",
- cl::desc("Run LTO passes using the new pass manager"),
- cl::init(true), cl::Hidden, cl::cat(LTOCategory));
-
 static cl::opt
 DebugPassManager("debug-pass-manager", cl::init(false), cl::Hidden,
  cl::desc("Print pass management debugging information"),
@@ -605,7 +600,6 @@
 ThinGenerator.setCacheMaxSizeFiles(ThinLTOCacheMaxSizeFiles);
 ThinGenerator.setCacheMaxSizeBytes(ThinLTOCacheMaxSizeBytes);
 ThinGenerator.setFreestanding(EnableFreestanding);
-ThinGenerator.setUseNewPM(UseNewPM);
 ThinGenerator.setDebugPassManager(DebugPassManager);
 
 // Add all the exported symbols to the table of symbols to preserve.
@@ -1016,6 +1010,7 @@
 
   CodeGen.setCodePICModel(codegen::getExplicitRelocModel());
   CodeGen.setFreestanding(EnableFreestanding);
+  CodeGen.setDebugPassManager(DebugPassManager);
 
   CodeGen.setDebugInfo(LTO_DEBUG_MODEL_DWARF);
   CodeGen.setTargetOptions(Options);
@@ -1070,8 +1065,6 @@
   CodeGen.setOptLevel(OptLevel - '0');
   CodeGen.setAttrs(codegen::getMAttrs());
 
-  CodeGen.setUseNewPM(UseNewPM);
-
   if (auto FT = codegen::getExplicitFileType())
 CodeGen.setFileType(FT.getValue());
 
Index: llvm/test/tools/llvm-lto2/X86/slp-vectorize-pm.ll
===
--- llvm/test/tools/llvm-lto2/X86/slp-vectorize-pm.ll
+++ llvm/test/tools/llvm-lto2/X86/slp-vectorize-pm.ll
@@ -2,19 +2,19 @@
 
 ; Test SLP and Loop Vectorization are enabled by default at O2 and O3.
 ; RUN: llvm-lto2 run %t1.bc -o %t2.o -O0 -r %t1.bc,foo,plx -debug-pass-manager \
-; RUN:  -use-new-pm -save-temps 2>&1 | FileCheck %s --check-prefix=CHECK-O0-SLP
+; RUN:  -save-temps 2>&1 | FileCheck %s --check-prefix=CHECK-O0-SLP
 ; RUN

[PATCH] D123300: [Clang] Enable opaque pointers by default

[Nikita Popov 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 rG702d5de4380b: [Clang] Enable opaque pointers by default 
(authored by nikic).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123300

Files:
  clang/CMakeLists.txt
  llvm/docs/OpaquePointers.rst


Index: llvm/docs/OpaquePointers.rst
===
--- llvm/docs/OpaquePointers.rst
+++ llvm/docs/OpaquePointers.rst
@@ -195,8 +195,10 @@
 
 
 As of April 2022 both LLVM and Clang have complete support for opaque pointers,
-but typed pointers are still the default. Opaque pointers will be enabled by
-default in Clang soon.
+and opaque pointers are enabled by default in Clang. It is possible to
+temporarily restore the old default using the
+``-DCLANG_ENABLE_OPAQUE_POINTERS=OFF`` cmake option. Opaque pointers can be
+disabled for a single Clang invocation using ``-Xclang -no-opaque-pointers``.
 
 The MLIR and Polly monorepo projects are not fully compatible with opaque
 pointers yet.
Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -251,7 +251,7 @@
 set(CLANG_ENABLE_OPAQUE_POINTERS "DEFAULT" CACHE STRING
 "Enable opaque pointers by default")
 if(CLANG_ENABLE_OPAQUE_POINTERS STREQUAL "DEFAULT")
-  set(CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL OFF)
+  set(CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL ON)
 elseif(CLANG_ENABLE_OPAQUE_POINTERS)
   set(CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL ON)
 else()


Index: llvm/docs/OpaquePointers.rst
===
--- llvm/docs/OpaquePointers.rst
+++ llvm/docs/OpaquePointers.rst
@@ -195,8 +195,10 @@
 
 
 As of April 2022 both LLVM and Clang have complete support for opaque pointers,
-but typed pointers are still the default. Opaque pointers will be enabled by
-default in Clang soon.
+and opaque pointers are enabled by default in Clang. It is possible to
+temporarily restore the old default using the
+``-DCLANG_ENABLE_OPAQUE_POINTERS=OFF`` cmake option. Opaque pointers can be
+disabled for a single Clang invocation using ``-Xclang -no-opaque-pointers``.
 
 The MLIR and Polly monorepo projects are not fully compatible with opaque
 pointers yet.
Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -251,7 +251,7 @@
 set(CLANG_ENABLE_OPAQUE_POINTERS "DEFAULT" CACHE STRING
 "Enable opaque pointers by default")
 if(CLANG_ENABLE_OPAQUE_POINTERS STREQUAL "DEFAULT")
-  set(CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL OFF)
+  set(CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL ON)
 elseif(CLANG_ENABLE_OPAQUE_POINTERS)
   set(CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL ON)
 else()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D123547: [docs] Mention that we are in the process of removing the legacy PM for the optimization pipeline

[Nikita Popov via Phabricator via cfe-commits]

nikic added inline comments.



Comment at: clang/docs/ClangCommandLineReference.rst:4
   NOTE: This file is automatically generated by running clang-tblgen
   -gen-opt-docs. Do not edit this file by hand!!
   ---

See this line :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123547

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

[PATCH] D123300: [Clang] Enable opaque pointers by default

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

@mstorsjo Thanks for the report, the issue should be fixed by 
https://github.com/llvm/llvm-project/commit/8d5c8d57c637d898094af323d1888ea5a3364f8c.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123300

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

[PATCH] D123300: [Clang] Enable opaque pointers by default

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

@vitalybuka Are there any instructions on how to reproduce failures from this 
buildbot? It seems like this needs more than a simple bootstrap build due to 
the need for instrumented libcxx?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123300

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

[PATCH] D123300: [Clang] Enable opaque pointers by default

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

Okay, I managed to reproduce this using the instructions from 
https://github.com/google/sanitizers/wiki/MemorySanitizerBootstrappingClang.

Reduced to these two variants for `-passes=msan`:

  target triple = "x86_64-unknown-linux-gnu"
  
  define void @test(i8* %p, i32* byval(i32) %p2) {
%p2.i8 = bitcast i32* %p2 to i8*
call void @llvm.memcpy.p0i8.p0i8.i64(i8* %p, i8* %p2.i8, i64 4, i1 false)
ret void
  }
  
  declare void @llvm.memcpy.p0i8.p0i8.i64(i8*, i8*, i64, i1)

  target triple = "x86_64-unknown-linux-gnu"
  
  define void @test(ptr %p, ptr byval(i32) %p2) {
call void @llvm.memcpy.p0.p0.i64(i8* %p, i8* %p2, i64 4, i1 false)
ret void
  } 
  
  declare void @llvm.memcpy.p0.p0.i64(i8*, i8*, i64, i1)

The second one does not initialize the shadow for the byval argument.

With typed pointers, this happens because a bitcast is present, which will 
attempt to fetch the shadow 
(https://github.com/llvm/llvm-project/blob/e810d558093cff40caaa1aff24d289c76c59916d/llvm/lib/Transforms/Instrumentation/MemorySanitizer.cpp#L2050).
 While a plain memcpy does not attempt to fetch the shadow 
(https://github.com/llvm/llvm-project/blob/e810d558093cff40caaa1aff24d289c76c59916d/llvm/lib/Transforms/Instrumentation/MemorySanitizer.cpp#L2586).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123300

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

[PATCH] D123300: [Clang] Enable opaque pointers by default

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

I've put up https://reviews.llvm.org/D123602 to fix the msan issue.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123300

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

[PATCH] D123547: [docs] Mention that we are in the process of removing the legacy PM for the optimization pipeline

[Nikita Popov via Phabricator via cfe-commits]

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

LG


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123547

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

[PATCH] D123300: [Clang] Enable opaque pointers by default

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

@mstorsjo Thanks! I've reduced this to a crash in `-argpromotion`:

  efine void @caller() {
call i32 @callee(ptr null)
ret void
  }
  
  define internal void @callee(ptr %p) {
ret void
  }

Similar issue with function type mismatch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123300

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

[PATCH] D123609: [Clang] Remove support for legacy pass manager

[Nikita Popov 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 rG2978d026819b: [Clang] Remove support for legacy pass manager 
(authored by nikic).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D123609?vs=45&id=422427#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123609

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/Driver/flegacy-pass-manager.c

Index: clang/test/Driver/flegacy-pass-manager.c
===
--- clang/test/Driver/flegacy-pass-manager.c
+++ clang/test/Driver/flegacy-pass-manager.c
@@ -1,29 +1,13 @@
-// RUN: %clang -### -c -flegacy-pass-manager -fno-legacy-pass-manager %s 2>&1 | FileCheck --check-prefixes=NOWARN,NEW %s
-// RUN: %clang -### -c -fno-legacy-pass-manager -flegacy-pass-manager %s 2>&1 | FileCheck --check-prefixes=NOWARN,LEGACY %s
+/// -fno-legacy-pass-manager and -fexperimental-new-pass-manager are retained
+// as no-ops. The inverted options are no longer supported.
 
-/// -fexperimental-new-pass-manager is a legacy alias. -fno-experimental-new-pass-manager has been removed.
-// RUN: %clang -### -c -fexperimental-new-pass-manager %s 2>&1 | FileCheck --check-prefixes=NOWARN,NEW %s
-// RUN: not %clang -### -fno-experimental-new-pass-manager %s
-
-// NOWARN-NOT: warning: argument unused
-
-// NEW:-fno-legacy-pass-manager
-// NEW-NOT:-flegacy-pass-manager
-
-// LEGACY: -flegacy-pass-manager
-// LEGACY-NOT: -fno-legacy-pass-manager
+// RUN: %clang -### -c -fno-legacy-pass-manager %s 2>&1 | FileCheck %s
+// RUN: not %clang -### -flegacy-pass-manager %s
 
-/// For full/Thin LTO, -fno-legacy-pass-manager passes -plugin-opt=new-pass-manager to the linker (which may not be LLD).
-// RUN: %clang -### -target x86_64-linux -flto -fno-legacy-pass-manager %s 2>&1 | FileCheck --check-prefix=LTO_NEW %s
-// RUN: %clang -### -target x86_64-linux -flto=thin -fexperimental-new-pass-manager %s 2>&1 | FileCheck --check-prefix=LTO_NEW %s
-
-// LTO_NEW:"-plugin-opt=new-pass-manager"
-
-// RUN: %clang -### -target x86_64-linux -flto -flegacy-pass-manager %s 2>&1 | FileCheck --check-prefix=LTO_LEGACY %s
+// RUN: %clang -### -c -fexperimental-new-pass-manager %s 2>&1 | FileCheck %s
+// RUN: not %clang -### -fno-experimental-new-pass-manager %s
 
-// LTO_LEGACY: "-plugin-opt=legacy-pass-manager"
+// Just check that there is no argument unused warning. There is no need to
+// pass any cc1 options.
 
-// RUN: %clang -### -target x86_64-linux -flto %s 2>&1 | FileCheck --check-prefix=DEFAULT %s
-//
-// DEFAULT-NOT: "-plugin-opt=new-pass-manager"
-// DEFAULT-NOT: "-plugin-opt=legacy-pass-manager"
+// CHECK-NOT: warning: argument unused
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -543,11 +543,6 @@
   << A->getSpelling() << T.getTriple();
   }
 
-  if (!CodeGenOpts.ProfileRemappingFile.empty() && CodeGenOpts.LegacyPassManager)
-Diags.Report(diag::err_drv_argument_only_allowed_with)
-<< Args.getLastArg(OPT_fprofile_remapping_file_EQ)->getAsString(Args)
-<< "-fno-legacy-pass-manager";
-
   return Diags.getNumErrors() == NumErrorsBefore;
 }
 
@@ -1731,10 +1726,6 @@
 
 // -ftime-report= is only for new pass manager.
 if (A->getOption().getID() == OPT_ftime_report_EQ) {
-  if (Opts.LegacyPassManager)
-Diags.Report(diag::err_drv_argument_only_allowed_with)
-<< A->getAsString(Args) << "-fno-legacy-pass-manager";
-
   StringRef Val = A->getValue();
   if (Val == "per-pass")
 Opts.TimePassesPerRun = false;
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -626,15 +626,6 @@
  Path));
   }
 
-  // Pass an option to enable/disable the new pass manager.
-  if (auto *A = Args.getLastArg(options::OPT_flegacy_pass_manager,
-options::OPT_fno_legacy_pass_manager)) {
-if (A->getOption().matches(options::OPT_flegacy_pass_manager))
-  CmdArgs.push_back("-plugin-opt=legacy-pass-manager");
-else
-  CmdArgs.push_back("-plugin-opt=new-pass-manager");
-  }
-
   // Setup statistics file output.
   SmallString<128> StatsFile = getStatsFileName(Args, Output, Input, D);
   if (!StatsFile.empty())
Index: clang/l

[PATCH] D123300: [Clang] Enable opaque pointers by default

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

@uabelho The IR is correct, but requires using `opt -opaque-pointers` 
explicitly. Normally, opaque pointer mode is automatically enabled, but there 
is no explicit mention of `ptr` in the IR. Not sure if we can do anything to 
improve that before the default on the opt side is switched.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123300

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

[PATCH] D123609: [Clang] Remove support for legacy pass manager

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

In D123609#3451320 , @HaohaiWen wrote:

> Hi @nikic,
> We recently noticed legacy PM was removed from many places.
> Does community plan to remove legacy PM completely?
> Do you know when will CG switch to new PM?
> Thanks.

At this time, the ability to run a middle-end optimization pipeline using the 
legacy pass manager (basically anything based on PassManagerBuilder) is being 
removed. The CodeGen pipeline continues to use the legacy pass manager at this 
time -- I'm not aware of anyone doing active migration work in that area.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123609

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

[PATCH] D123957: Update the developer policy to mention release notes

[Nikita Popov via Phabricator via cfe-commits]

nikic requested changes to this revision.
nikic added inline comments.
This revision now requires changes to proceed.



Comment at: llvm/docs/DeveloperPolicy.rst:195
+* Adding, removing, or regrouping a diagnostic.
+* Fixing a bug (please link to the issue fixed in the bug database).
+* Adding or removing an optimization.

I disagree with this point. Bug fixes should not make it into the release notes 
as a matter of course -- there may be specific high-impact bug fixes that may 
be worth mentioning, but bug fixes should not be included in the release notes 
as a matter of policy.

I agree that release notes for Clang/LLVM are currently insufficient, but we 
should also be careful not to over-compensate in the other direction, but 
including too much irrelevant noise.


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

https://reviews.llvm.org/D123957

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

[PATCH] D123300: [Clang] Enable opaque pointers by default

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

@markus Without tracing through it in detail, I'd guess that without opaque 
pointers this creates two getelementptr constant expressions that get folded 
together. With opaque pointers, the first one (which would be a zero-index GEP) 
is omitted, and only the second one is left. ConstantFolding will later 
canonicalize the GEP source type, but this only happens when InstCombine runs, 
while you're looking at unoptimized IR.

Are you encountering some particular issue relating to this? For well-written 
optimizations, the exact GEP representation shouldn't matter either way.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123300

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