The lock tables were being reallocated if kmp_set_defaults() was called.
In the env_init code it says that the user should be able to switch between
different KMP_CONSISTENCY_CHECK values which is what this change enables.

llvm-svn: 292349

There is no corresponding free() for this expandable array.  The logic is
added in __kmp_cleanup() next to the freeing of __kmp_nested_nth.

llvm-svn: 292348

The buildbots currently depend on the old configuration. I'll recommit
once Zorg is fixed and reset

llvm-svn: 292347

llvm-svn: 292346

Adding `path::operator=(string_type&&)` made the expression `p = {}`
ambiguous. This path fixes that ambiguity by making the `string&&`
overload a template so it ranks lower during overload resolution.

llvm-svn: 292345

These two are independent: it's possible to use LLD without LTO,
and it's possible to do LTO build without LLD.

Differential Revision: https://reviews.llvm.org/D28821

llvm-svn: 292343

llvm-svn: 292342

llvm-svn: 292337

This patch adds a test for an invalid output path for -Map option,
though that test is not for verifying that we are using error()
instead of fatal() in writeMapFile.

llvm-svn: 292336

Ported from the amd-builtins branch.

Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Matt Arsenault <Matthew.Arsenault@amd.com>
CC: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 292335

Ported from the amd-builtins branch.

Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Matt Arsenault <Matthew.Arsenault@amd.com>
CC: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 292334

follow LLVM's naming conventions while I'm here.

Again, sorry I didn't spot this earlier to coalesce with other cleanup
changes.

llvm-svn: 292333

deleted.

I've expanded its test coverage a bit including adding one test that
will crash clearly without this change.

llvm-svn: 292332

claims to test.

LoopSimplify was unifying the multiple exits in this test case, making
it never even test the multiple exit handling of LoopDeletion. Doh.

Now it works (thanks to a great idea from mkuper) and will fail if we
ever change something to make it stop working.

llvm-svn: 292331

Although this relocation type is not part of the x86-64 psABI, I intend to
use it internally as part of the ThinLTO implementation.

Differential Revision: https://reviews.llvm.org/D28841

llvm-svn: 292330

Verified that the backend codegens this equally well.

llvm-svn: 292329

llvm-svn: 292328

llvm-svn: 292327

llvm-svn: 292326

llvm-svn: 292325

The grow_memory instruction now returns the previous memory size. Add the
return type to the clang intrinsic.

llvm-svn: 292324

Reviewers: zinob, hans, grosser

Reviewed By: hans, grosser

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D28712

llvm-svn: 292323

The grow_memory instruction now returns the previous memory size. Add the
return type to the LLVM intrinsic.

llvm-svn: 292322

You can now define the register class of a virtual register on the
operand itself avoiding the need to use a "registers:" block.

Example: "%0:gr64 = COPY %rax"

Differential Revision: https://reviews.llvm.org/D22398

llvm-svn: 292321

[Target, Transforms] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC).

llvm-svn: 292320

llvm-svn: 292319

llvm-svn: 292318

Reviewers: tra, majnemer

Subscribers: llvm-commits, jholewinski

Differential Revision: https://reviews.llvm.org/D28825

llvm-svn: 292316

llvm-svn: 292315

llvm-svn: 292310

Summary: The parameter `input` to `subprocess.Popen.communicate(...)` must be an object of type `bytes` . This is strictly enforced in python3. This patch (1) allows `to_bytes` to be safely called redundantly. (2) Explicitly convert `input` within `executeCommand`. This allows for usages like `executeCommand(['clang++', '-'], input='int main() {}\n')`.

Reviewers: ddunbar, BinaryKhaos, modocache, dim, EricWF

Reviewed By: EricWF

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D28736

llvm-svn: 292308

Some instructions were printed as "foo\tbar", but most are printed as
"foo \bar".  Standardize on the latter form.

llvm-svn: 292306

!strconcat is a variadic function; it will concatenate an arbitrary
number of strings.  There's no need to nest it.

llvm-svn: 292305

Summary:
This change also lets us use max.{s,u}16.  There's a vague warning in a
test about this maybe being less efficient, but I could not come up with
a case where the resulting SASS (sm_35 or sm_60) was different with or
without max.{s,u}16.  It's true that nvcc seems to emit only
max.{s,u}32, but even ptxas 7.0 seems to have no problem generating
efficient SASS from max.{s,u}16 (the casts up to i32 and back down to
i16 seem to be implicit and nops, happening via register aliasing).

In the absence of evidence, better to have fewer special cases, emit
more straightforward code, etc.  In particular, if a new GPU has 16-bit
min/max instructions, we want to be able to use them.

Reviewers: tra

Subscribers: jholewinski, llvm-commits

Differential Revision: https://reviews.llvm.org/D28732

llvm-svn: 292304

Summary: Previously we lowered it literally, to shifts and xors.

Reviewers: tra

Subscribers: jholewinski, llvm-commits

Differential Revision: https://reviews.llvm.org/D28722

llvm-svn: 292303

Summary:
Avoid an unnecessary conversion operation when using the result of
ctpop.i32 or ctpop.i16 as an i32, as in both cases the ptx instruction
we run returns an i32.

(Previously if we used the value as an i32, we'd do an unnecessary
zext+trunc.)

Reviewers: tra

Subscribers: jholewinski, llvm-commits

Differential Revision: https://reviews.llvm.org/D28721

llvm-svn: 292302

Reviewers: tra

Subscribers: llvm-commits, jholewinski

Differential Revision: https://reviews.llvm.org/D28720

llvm-svn: 292301

Looks like a copy/paste mistake, all the functions in ctlz.ll were named
"ctpop".

llvm-svn: 292300

Summary:
* Disable "ctlz speculation", which inserts a branch on every ctlz(x) which
  has defined behavior on x == 0 to check whether x is, in fact zero.

* Add DAG patterns that avoid re-truncating or re-expanding the result
  of the 16- and 64-bit ctz instructions.

Reviewers: tra

Subscribers: llvm-commits, jholewinski

Differential Revision: https://reviews.llvm.org/D28719

llvm-svn: 292299

llvm-svn: 292298