llvm-svn: 362655

The AllConstant check needs to be moved out of the if/else if chain to
avoid a test regression. The "there is no SimplifyZExt" comment
puzzles me, since there is SimplifyCastInst. Additionally, the
Simplify* calls seem to not see the operand as constant, so this needs
to be tried if the simplify failed.

llvm-svn: 362653

LLVM IR recently added a Type parameter to the byval Attribute, so that
when pointers become opaque and no longer have an element type the
information will still be present in IR.

For now the Type parameter is optional (which is why Clang didn't need
this change at the time), but it will become mandatory soon.

llvm-svn: 362652

llvm-svn: 362651

We were not previously testing the comdat exclusion in bitcode objects
because we were linking two copies of the .bc file and the
`linkonce_odr` linkage type was removing the duplicate `_start` at
the LTO stage.

Now we link an bitcode and non-bitcode version both of which contains a
copy of _start.  We link them in both orders, which means this test will
fail if comdat exclusion is not working correctly in bitcode parsing.

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

llvm-svn: 362650

Speedup to_string and to_wstring for integers using stack buffer and SSO. Reviewed as https://reviews.llvm.org/D59178  Thanks to ivafanas for all his work on this patch.

llvm-svn: 362649

[X86] Fix mistake that marked VADDSSrrb_Int/VADDSDrrb_Int/VMULSSrrb_Int/VMULSDrrb_Int as commutable.

One of the sources controls the pass through value for the upper bits
of the result so we can't really commute it.

In practice this problem isn't a functional issue because we would
only try to commute this instruction in order to fold a load. But
we can't do embedded rounding and fold a load at the same time. So
the load fold would never succeed so I don't think we would ever
commute or at least keep the version after commuting.

llvm-svn: 362647

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

llvm-svn: 362646

With r362638, llc doesn't support -relocation-model=pic with non-Emscripten
triples. Update these tests in lld which use -relocation-model=pic to also
use Emscripten triples.

llvm-svn: 362645

step, and loop induction variable.

Summary: This PR extends the loop object with more utilities to get loop
bounds, step, and loop induction variable. There already exists passes
which try to obtain the loop induction variable in their own pass, e.g.
loop interchange. It would be useful to have a common area to get these
information.

/// Example:
/// for (int i = lb; i < ub; i+=step)
///   <loop body>
/// --- pseudo LLVMIR ---
/// beforeloop:
///   guardcmp = (lb < ub)
///   if (guardcmp) goto preheader; else goto afterloop
/// preheader:
/// loop:
///   i1 = phi[{lb, preheader}, {i2, latch}]
///   <loop body>
///   i2 = i1 + step
/// latch:
///   cmp = (i2 < ub)
///   if (cmp) goto loop
/// exit:
/// afterloop:
///
/// getBounds
///   getInitialIVValue      --> lb
///   getStepInst            --> i2 = i1 + step
///   getStepValue           --> step
///   getFinalIVValue        --> ub
///   getCanonicalPredicate  --> '<'
///   getDirection           --> Increasing
/// getInductionVariable          --> i1
/// getAuxiliaryInductionVariable --> {i1}
/// isCanonical                   --> false

Reviewers: kbarton, hfinkel, dmgreen, Meinersbur, jdoerfert, syzaara,
fhahn
Reviewed By: kbarton
Subscribers: tvvikram, bmahjour, etiotto, fhahn, jsji, hiraditya,
llvm-commits
Tag: LLVM
Differential Revision: https://reviews.llvm.org/D60565

llvm-svn: 362644

When the byval attribute has a type, it must match the pointee type of
any parameter; but InstCombine was not updating the attribute when
folding casts of various kinds away.

llvm-svn: 362643

Most parts of LLVM don't care whether the byval type is derived from an
explicit Attribute or from the parameter's pointee type, so it makes
sense for the main access function to just return the right value.

The very few users who do care (only BitcodeReader so far) can find out
how it's specified by accessing the Attribute directly.

llvm-svn: 362642

This has been deprecated for a long time, and mesa recently switched
to amdgpu-flat-work-group-size.

llvm-svn: 362641

These enums are really for the same namespace of flags set on
arbitrary MachineOperands, so merge them to avoid value collisions.

llvm-svn: 362640

llvm-svn: 362639

The current PIC support currently only works with Emscripten, so
disable it for other targets.

This is the PIC portion of https://reviews.llvm.org/D62542.

Reviewed By: dschuff, sbc100

llvm-svn: 362638

Summary: This patch cleans up a duplicate use of TestingSupport library.

Subscribers: mgorny, cfe-commits

Tags: #clang

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

llvm-svn: 362637

Summary:
See D60593 for further information.

This patch introduces the core of GWP-ASan, being the guarded pool allocator. This class contains the logic for creating and maintaining allocations in the guarded pool. Its public interface is to be utilised by supporting allocators in order to provide sampled guarded allocation behaviour.

This patch also contains basic functionality tests of the allocator as unittests. The error-catching behaviour will be tested in upcoming patches that use Scudo as an implementing allocator.

Reviewers: vlad.tsyrklevich, eugenis, jfb

Reviewed By: vlad.tsyrklevich

Subscribers: dexonsmith, kubamracek, mgorny, cryptoad, jfb, #sanitizers, llvm-commits, morehouse

Tags: #sanitizers, #llvm

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

llvm-svn: 362636

Some already combine correctly, but vector constant analysis is weak.

llvm-svn: 362633

Summary: Sometimes we are at character boundaries so past the token-range.
llvm-svn: 362632

Missed 2 'fast fsub(0.0,X) -> fneg(X)' changes.

llvm-svn: 362631

llvm-svn: 362630

As far as I know these should be freely reassociatable just like
the floating point MAXC/MINC instructions.

The *reduce* test changes are largely regressions and caused by
the "generic" CPU we default to not having a scheduler model.

The machine-combiner-int-vec.ll test shows the positive benefits
of this change.

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

llvm-svn: 362629

[Tests] Add poison inference tests for indvars showing both existing transforms, and some room for improvement

llvm-svn: 362628

llvm-svn: 362627

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

llvm-svn: 362626

Any symbols defined in the LTO object are by definition the ones we
want in the final output so we skip the comdat group checking in those
cases.

This change makes the ELF code more explicit about this and means
that wasm and ELF do this in the same way.

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

llvm-svn: 362625

Summary:
In DistributionExample.cmake be sure we use a LTO
capable linker, the easiest to choose is lld.

Reviewers: beanz

Reviewed By: beanz

Patch By: winksaville

Subscribers: mgorny, mehdi_amini, inglorion, dexonsmith, cfe-commits

Tags: #clang

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

llvm-svn: 362624

Patch by richardmembarth (Richard Membarth)!

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

llvm-svn: 362623

llvm-svn: 362622

When running dsymutil on a fat binary, we use temporary files in a small
vector of size four. When processing more than 4 architectures, this
resulted in a user-after-move, because the temporary files got moved to
the heap. Instead of storing an optional temp file, we now use a unique
pointer, so the location of the actual temp file doesn't change.

We could test this by checking in 5 binaries for 5 different
architectures, but this seems wasteful, especially since the number of
elements in the small vector is arbitrary.

llvm-svn: 362621

As suggested in D62498 - collectConcatOps() matches both
concat_vectors and insert_subvector patterns, and we see
more test improvements by using the more general match.

llvm-svn: 362620

Summary:
Once we've attached to the process we load all current modules and also set a breakpoint at the rendezvous break address.
However, we don't do this if we already have a load address for the image info address (e.g.: DT_DEBUG on ELF). This code was added 4 years ago when adding support for `$qXfer:Libraries:` packet (https://reviews.llvm.org/D9471) but its intention is not 100% clear to me. It seems to me we're using that check to know if the modules have already been loaded (which they have if `$qXfer:Libraries:` is supported by the gdb server) and skip loading the modules again in the following `if` block. The problem is that we also skip setting the Rendezvous breakpoint so we stop knowing when the process loads new modules.
I fix this by moving the call to set the breakpoint to the end of the function so we always call it as long as we have a valid executable.

Reviewers: ADodds, clayborg, eugene, labath

Reviewed By: eugene, labath

Subscribers: lldb-commits

Tags: #lldb

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

llvm-svn: 362619

Currently implemented only for non-Windows 64-bit platforms.

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

llvm-svn: 362618

Enables us to use this to split 512-bit vectors in future patches.

llvm-svn: 362617

llvm-svn: 362616

This reverts commit d34797df.

llvm-svn: 362615

We can remove this TODOs now.

Differential revision: https://reviews.llvm.org/D62846

llvm-svn: 362614

    
This patch fixes a regression caused by the operand reordering refactoring patch https://reviews.llvm.org/D59973 .
The fix changes the strategy to Splat instead of Opcode, if broadcast opportunities are found.
Please see the lit test for some examples.

Committed on behalf of @vporpo (Vasileios Porpodas)
    
Differential Revision: https://reviews.llvm.org/D62427

llvm-svn: 362613

Instead of passing around fast-math-flags as a parameter, we can set those
using an IRBuilder guard object. This is no-functional-change-intended.

The motivation is to eventually fix the vectorizers to use and set the
correct fast-math-flags for reductions. Examples of that not behaving as
expected are:
https://bugs.llvm.org/show_bug.cgi?id=23116 (should be able to reduce with less than 'fast')
https://bugs.llvm.org/show_bug.cgi?id=35538 (possible miscompile for -0.0)
D61802 (should be able to reduce with IR-level FMF)

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

llvm-svn: 362612