Summary: [JumpThread] Do RAUW in case Cond folds to a constant in the CFG
Reviewers: sanjoy
Reviewed By: sanjoy
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32407
llvm-svn: 301804
These test cases occassionally fail when run on powerpc64le:
ignore_lib1.cc
ignore_lib5.cc
TestCases/Posix/current_allocated_bytes.cc
rtl/TsanRtlTest/Posix.ThreadLocalAccesses
TestCases/Posix/coverage-fork-direct.cc
The failures cause false problem reports to be sent to developers whose
code had nothing to do with the failures. Reactivate them when the real
problems are fixed.
This could also be related to the same problems as with the tests
ThreadedOneSizeMallocStressTest, ThreadedMallocStressTest, ManyThreadsTest,
and several others that do not run reliably on powerpc.
llvm-svn: 301798
In this patch, I introduce a new alt macro feature.
This feature adds meaning for the % when using it as a prefix to the calling macro arguments.
In the altmacro mode, the percent sign '%' before an absolute expression convert the expression first to a string.
As described in the https://sourceware.org/binutils/docs-2.27/as/Altmacro.html
"Expression results as strings
You can write `%expr' to evaluate the expression expr and use the result as a string."
expression assumptions:
1. '%' can only evaluate an absolute expression.
2. Altmacro '%' must be the first character of the evaluated expression.
3. If no '%' is located before the expression, a regular module operation is expected.
4. The result of Absolute Expressions can be only integer.
Differential Revision: https://reviews.llvm.org/D32526
llvm-svn: 301797
For a linker init mutex with lazy flag setup
(no __tsan_mutex_create call), it is possible that
no lock/unlock happened before the destroy call.
Then when destroy runs we still don't know that
it is a linker init mutex and will emulate a memory write.
This in turn can lead to false positives as the mutex
is in fact linker initialized.
Support linker init flag in destroy annotation to resolve this.
llvm-svn: 301795
Summary:
Unless I'm missing something, the DeferredGlobal struct's GV field is
unused, removing which makes the struct itself trivial.
Reviewers: rafael, chandlerc
Subscribers: mcrosier, llvm-commits
Differential Revision: https://reviews.llvm.org/D32691
llvm-svn: 301789
Summary:
In this patch we document the requirements for implementations that want
to install handlers for the dynamically-controlled XRay "framework".
This clarifies what the expectations are for implementations that
want to install their handlers using this API (similar to how the FDR
logging implementation does so). It also gives users some guarantees on
semantics for the APIs.
If all goes well, users can decide to use the XRay APIs to control the
tracing/logging at the application level, without having to depend on
implementation details of the installed logging implementation. This
lets users choose the implementation that comes with compiler-rt, or
potentially multiple other implementations that use the same APIs.
We also add one convenience function (__xray_remove_log_impl()) for
explicitly removing the currently installed log implementation.
Reviewers: kpw, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32579
llvm-svn: 301784
We discussed shrinking/widening of selects in IR in D26556, and I'll try to get back to that
patch eventually. But I'm hoping that this transform is less iffy in the DAG where we can check
legality of the select that we want to produce.
A few things to note:
1. We can't wait until after legalization and do this generically because (at least in the x86
tests from PR14657), we'll have PACKSS and bitcasts in the pattern.
2. This might benefit more of the SSE codegen if we lifted the legal-or-custom requirement, but
that requires a closer look to make sure we don't end up worse.
3. There's a 'vblendv' opportunity that we're missing that results in andn/and/or in some cases.
That should be fixed next.
4. I'm assuming that AVX1 offers the worst of all worlds wrt uneven ISA support with multiple
legal vector sizes, but if there are other targets like that, we should add more tests.
5. There's a codegen miracle in the multi-BB tests from PR14657 (the gcc auto-vectorization tests):
despite IR that is terrible for the target, this patch allows us to generate the optimal loop
code because something post-ISEL is hoisting the splat extends above the vector loops.
Differential Revision: https://reviews.llvm.org/D32620
llvm-svn: 301781
To make the TSan external API work with Swift and other use cases, we need to track "tags" for individual memory accesses. Since there is no space to store this information in shadow cells, let's use the thread traces for that. This patch stores the tag as an extra frame in the stack traces (by calling FuncEntry and FuncExit with the address of a registered tag), this extra frame is then stripped before printing the backtrace to stderr.
Differential Revision: https://reviews.llvm.org/D32382
llvm-svn: 301777
Summary:
programUndefinedIfPoison makes more sense, given what the function
does; and I'm about to add a function with a name similar to
isKnownNotFullPoison (so do the rename to avoid confusion).
Reviewers: broune, majnemer, bjarke.roune
Reviewed By: broune
Subscribers: mcrosier, llvm-commits, mzolotukhin
Differential Revision: https://reviews.llvm.org/D30444
llvm-svn: 301776
Summary: As per discution on how to get better codegen an large int legalization, it became clear that using a glue for the carry was preventing several desirable optimizations. Passing the carry down as a value allow for more flexibility.
Reviewers: jyknight, nemanjai, mkuper, spatel, RKSimon, zvi, bkramer
Subscribers: igorb, llvm-commits
Differential Revision: https://reviews.llvm.org/D29872
llvm-svn: 301775
When the -no-keep-memory option is given, BFD linker tries to save
memory in their own way. Since our internal architecture is completely
different from that linker, that option doesn't make sense to us.
llvm-svn: 301772
This features isn't used anywhere in tree. It's existence seems to be preventing selfhost builds from inlining any of the setBits methods including setLowBits, setHighBits, and setBitsFrom. This is because the code makes the method recursive.
If anyone needs this feature in the future we could consider adding a setBitsWithWrap method. This way only the calls that need it would pay for it.
llvm-svn: 301769
Summary:
Apply canonicalization rules:
1. Input vectors with no elements selected from can be replaced with undef.
2. If only one input vector is constant it shall be the second one.
This allows constant-folding to cover more ad-hoc simplifications that
were in place and avoid duplication for RHS and LHS checks.
There are more rules we may want to add in the future when we see a
justification. e.g. mask elements that select undef elements can be
replaced with undef.
Reviewers: spatel, RKSimon, andreadb, davide
Reviewed By: spatel, RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32338
llvm-svn: 301766
In case of microMIPS mode %gottprel operator should emit microMIPS
relocation R_MICROMIPS_TLS_GOTTPREL, not R_MIPS_TLS_GOTTPREL.
Differential Revision: http://reviews.llvm.org/D32617
llvm-svn: 301763
For an option -foo-bar-baz, we have Config->FooBarBaz. Since -rpath is
-rpath and not -r-path, it should be Config->Rpath instead Config->RPath.
llvm-svn: 301759
Adrian Prantl