Of course, we really need to refactor and fix all of the cmp predicates, 
but this one is interesting because without it, we later perform an 
information-losing transform of icmp (shl 1, Y), C, and we can't recover
the better fold.

llvm-svn: 279263

This patch is opposite to D19024, which made this symbols to be hidden by default.

Unfortunately FreeBSD loader wants to see
start_set_modmetadata_set/stop_set_modmetadata_set in the dynamic symbol table. 
They were not placed there because had hidden visibility.

Patch makes them to have default visibility again.

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

llvm-svn: 279262

[LTO] Remove dead-code: collectUsedGlobalVariables has been moved to Thin and LTO specifc path (NFC)

llvm-svn: 279261

llvm-svn: 279259

Previously DT_PREINIT_ARRAYSZ, DT_INIT_ARRAYSZ and DT_FINI_ARRAYSZ
were set to zero when lincerscript was used becase sections sizes are
calculated later that were taken.

Patch delays values calculation for these entries. Testcase is provided.

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

llvm-svn: 279258

These are implicitly included as part of larger test cases, but they don't 
exist stand-alone (and don't happen for vectors...).

llvm-svn: 279257

You can force input section alignment within an output section by using SUBALIGN. The
value specified overrides any alignment given by input sections, whether larger or smaller.

SUBALIGN is used in many projects in the wild.

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

llvm-svn: 279256

llvm-svn: 279255

llvm-svn: 279254

Introduce a new CMake option `COMPILER_RT_SANITIZERS_TO_BUILD` which takes
either a special token `all` (default) which will preserve the current behaviour
or a CMake list of sanitizers to build.  It will still perform the normal checks
if the sanitizer is requested.  It only permits a further means to exclude a
particular sanitizer.  This gives finer grained control than
`COMPILER_RT_BUILD_SANITIZERS` which only gives an all or nothing control.

llvm-svn: 279253

llvm-svn: 279252

Patch by Arnold Schwaighofer.

llvm-svn: 279251

Summary: E.g. `{a: 1} as b`.

Reviewers: djasper

Subscribers: cfe-commits, klimek

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

llvm-svn: 279250

Patch by Brendon Cahoon.

llvm-svn: 279249

llvm-svn: 279248

llvm-svn: 279247

llvm-svn: 279246

llvm-svn: 279245

llvm-svn: 279244

llvm-svn: 279243

In addition, the branch instructions will have proper BB destinations, not offsets, like before.

Patch by Vadzim Dambrouski!

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

llvm-svn: 279242

llvm-svn: 279241

llvm-svn: 279240

Improved handling of fma, floating point min/max, additional load/store
instructions for floating point types.

Patch by Jyotsna Verma.

llvm-svn: 279239

GetByteSize() of a DataBuffer returns a uint64_t (it probably shouldn't), which isn't implicitly
convertible to size_t.

llvm-svn: 279238

Summary:
The Print() members might take optional access_size and bug_type
parameters to still be able to provide the same information

Reviewers: kcc, samsonov

Subscribers: kubabrecka, llvm-commits

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

llvm-svn: 279237

llvm-svn: 279236

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

llvm-svn: 279235

The pexpect import should be make after the skip-if-not-darwin part
because pexpect is not available on Windows

llvm-svn: 279234

llvm-svn: 279233

Summary:
The tricky part here was that the exisiting implementation of WriteAllRegisters was expecting
hex-encoded data (as that was what the first implementation I replaced was using, but here we had
binary data to begin with. I thought the read/write register functions would be more useful if
they handled the hex-encoding themselves (all the other client functions provide the responses in
a more-or-less digested form). The read functions return a DataBuffer, so they can allocate as
much memory as they need to, while the write functions functions take an llvm::ArrayRef, as that
can be constructed from pretty much anything.

Reviewers: clayborg

Subscribers: lldb-commits

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

llvm-svn: 279232

solve completely opaque MSVC build errors. It complains about lots of
stuff with this change without givin nearly enough information to even
try to fix.

llvm-svn: 279231

INSERTPS doesn't fit well with our shuffle mask canonicalization, so we need to attempt both the original mask and the commuted mask to more likely get a match

llvm-svn: 279230

The new version has several advantages:
  1) IMSHO it's more readable and neater
  2) It handles loads and stores properly
  3) It can handle any number of incoming blocks rather than just two. I'll be taking advantage of this in a followup patch.

With this change we can now finally sink load-modify-store idioms such as:

    if (a)
      return *b += 3;
    else
      return *b += 4;

    =>

    %z = load i32, i32* %y
    %.sink = select i1 %a, i32 5, i32 7
    %b = add i32 %z, %.sink
    store i32 %b, i32* %y
    ret i32 %b

When this works for switches it'll be even more powerful.

llvm-svn: 279229

llvm-svn: 279228

to run methods, both for transform passes and analysis passes.

This also allows the analysis manager to use a different set of extra
arguments from the pass manager where useful. Consider passes over
analysis produced units of IR like SCCs of the call graph or loops.
Passes of this nature will often want to refer to the analysis result
that was used to compute their IR units (the call graph or LoopInfo).
And for transformations, they may want to communicate special update
information to the outer pass manager. With this change, it becomes
possible to have a run method for a loop pass that looks more like:

  PreservedAnalyses run(Loop &L, AnalysisManager<Loop, LoopInfo> &AM,
                        LoopInfo &LI, LoopUpdateRecord &UR);

And to query the analysis manager like:

    AM.getResult<MyLoopAnalysis>(L, LI);

This makes accessing the known-available analyses convenient and clear,
and it makes passing customized data structures around easy.

My initial use case is going to be in updating the pass manager layers
when the analysis units of IR change. But there are more use cases here
such as having a layer that lets inner passes signal whether certain
additional passes should be run because of particular simplifications
made. Two desires for this have come up in the past: triggering
additional optimization after successfully unrolling loops, and
triggering additional inlining after collapsing indirect calls to direct
calls.

Despite adding this layer of generic extensibility, the *only* change to
existing, simple usage are for places where we forward declare the
AnalysisManager template. We really shouldn't be doing this because of
the fragility exposed here, but currently it makes coping with the
legacy PM code easier.

Differential Revision: http://reviews.llvm.org/D21462

llvm-svn: 279227

llvm-svn: 279226

r279217 where it fails to select the path that other compilers select.

The workaround won't be as careful to produce an error when an analysis
result is incorrect, but we can rely on non-MSVC builds to catch such
errors it seems and MSVC doesn't seem to support the alternative
techniques.

Hoping this brings the windows bots back to life. If not, will have to
revert all of this.

llvm-svn: 279225

The heuristic above this code is incredibly suspect, but disregarding that it mutates the cast opcode so we need to check the *mutated* opcode later to see if we need to emit an AssertSext or AssertZext node.

Fixes PR29041.

llvm-svn: 279223

Summary: r279178 generates 8 times more stores than necessary.

Reviewers: eugenis

Subscribers: llvm-commits

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

llvm-svn: 279222