AMDGPU: Simplify boolean conditional return statements

Patch by Richard Thomson

llvm-svn: 262536

Add new OpenMP 4.5 taskloop construct feature

From the standard: The taskloop construct specifies that the iterations of one
or more associated loops will be executed in parallel using OpenMP tasks. The
iterations are distributed across tasks created by the construct and scheduled
to be executed.

This initial implementation uses a simple linear tasks distribution algorithm.
Later we can add other algorithms to speedup generation of huge number of tasks
(i.e., tree-like tasks generation should be faster).

This needs to be put into the OpenMP runtime library in order for the
compiler team to develop the compiler side of the implementation.

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

llvm-svn: 262535

clang-format: [JS] Optionally re-quote string literals.

Turns "foo" into 'foo' (or vice versa, depending on configuration).
This makes it more convenient to follow the Google JavaScript style
guide:
https://google.github.io/styleguide/javascriptguide.xml?showone=Strings#Strings

This functionality is behind the option "JavaScriptQuotes", which can be:

  * "leave" (no re-quoting)
  * "single" (change to single quotes)
  * "double" (change to double quotes)

This also changes single quoted JavaScript string literals to be treated
as tok::string_literal, not tok::char_literal, which fixes two unrelated
tests.

Patch by Martin Probst. Thank you.

llvm-svn: 262534

Forgot to add test files for doacross and task priority.

llvm-svn: 262533

Add new OpenMP 4.5 doacross loop nest feature

From the standard: A doacross loop nest is a loop nest that has cross-iteration
dependence. An iteration is dependent on one or more lexicographically earlier
iterations. The ordered clause parameter on a loop directive identifies the
loop(s) associated with the doacross loop nest.

The init/fini routines allocate/free doacross buffer(s) for each loop for each
thread.  The wait routine waits for a flag designated by the dependence vector.
The post routine sets the flag designated by current iteration vector.  We use
a similar technique of shared buffer indices that covers up to 7 nowait loops
executed simultaneously by different threads (number 7 has no real meaning,
just heuristic value).  Also, the size of structures are kept intact via
reducing dummy arrays.

This needs to be put into the OpenMP runtime library in order for the compiler
team to develop the compiler side of the implementation.

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

llvm-svn: 262532

[MBP] Remove overly verbose debug output

llvm-svn: 262531

Explode store of arrays in instcombine

Summary: This is the last step toward supporting aggregate memory access in instcombine. This explodes stores of arrays into a serie of stores for each element, allowing them to be optimized.

Reviewers: joker.eph, reames, hfinkel, majnemer, mgrang

Subscribers: llvm-commits

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

llvm-svn: 262530

[llvm-nm] Restore the previous behaviour (pre r262525).

It broke some buildbots.

Pointy-hat to:  me

llvm-svn: 262529

Add support for reading line tables from PDB files.

PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.

Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows.  This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.

This patch only adds support for line tables.  It does not return
information about functions, types, global variables, or anything
else.  This functionality will be added in a followup patch.

Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton

llvm-svn: 262528

Add some minimal portability code paths for PS4.

Summary:
Hi David, SCE folks,

What is implemented in this patch is enough for the upstream libprofile to
work for PGO with the PS4 game codebase I tested ("game7" for you SCE
folks; this is with a standalone build of compiler-rt).

The first change, which is simple, is to stub out gethostname. PS4
doesn't have a simple analog for this that doesn't bring in extra
OS libraries, so for now we do not support `%h` expansion.
This is consistent with internal B#136272.

The second change implies future work, but is a simple change at present.
PS4 does not have `getenv`, so for now we will introduce a shim.
This obviously makes it impossible for many of the tests to be run since
they require setting `LLVM_PROFILE_FILE=`.

I see two paths forward:

1. In the tests we are already wrapping execution with `%run` and so by
   setting a PS4-specific expansion for `%run` we can pass the information
   in another way We can adapt the getenv shim as appropriate.
   We will need to experiment with this internally.
   Maggie, Phillip, Filipe? Any ideas? Maybe ping me internally since we
   may need to get into some PS4 vagaries. I'm thinking a fake getenv
   library that uses some side channel for communication.

2. Another possibility which is more verbose is to use a separate clang
   invocation with `-profile-generate=<filename>` to set the filename in
   each test.
   This might require redundant clang invocations though which may be
   undesirable for upstream. David, thoughts?
   Also, this is a fairly libprofile-specific workaround, so it e.g.
   doesn't help Filipe's ASan work.
   Overall, this approach sounds like a bit of a hack to me.

Small detail:
InstrProfilingPort.h seems like the natural place for the getenv shim,
but GCDAProfiling.c needs it as well. InstrProfilingUtil.h is currently
the only header common between InstrProfilingFile.c and GCDAProfiling.c.
I can move the shim to InstrProfilingPort.h and add an include to
GCDAProfiling.c as per your preference David.

Reviewers: davidxl, MaggieYi, phillip.power, filcab

Subscribers: simon.f.whittaker, slingn, probinson, llvm-commits

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

llvm-svn: 262527

[analyzer] Move ObjCSuperDeallocChecker out of the alpha package.

It will now be on by default on Darwin.

rdar://problem/6953275

llvm-svn: 262526

[llvm-nm] Fix rendering of -s grouping with all the othe options.

llvm-svn: 262525

[analyzer] Move ObjCDeallocChecker out of the alpha package.

It will now be on by default on Darwin.

rdar://problem/6927496

llvm-svn: 262524

[MBP] Adjust debug output to be more focused and approachable

llvm-svn: 262522

Unpack array of all sizes in InstCombine

Summary: This is another step toward improving fca support. This unpack load of array in a series of load to array's elements.

Reviewers: chandlerc, joker.eph, majnemer, reames, hfinkel

Subscribers: llvm-commits

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

llvm-svn: 262521

[analyzer] Fix capitalization in ObjCSuperDeallocChecker diagnostic.

llvm-svn: 262520

Really fix ASAN leak/etc issues with MemorySSA unittests

llvm-svn: 262519

Use ld.lld instead of "lld -flavor gnu".

llvm-svn: 262518

[libFuzzer] add -Werror for libFuzzer build rule

llvm-svn: 262517

Fixed test failure platforms with name mangling different from Linux.
* Run cc with -triple x86_64-linux-gnu to make symbol mangling predictable.
* Use temporary file as a fake GPU input so its content
  does not interfere with pattern matching.

llvm-svn: 262516

[PGO] Change profile use cc1 option to handle IR level profiles

This patch changes cc1 option for PGO profile use from
-fprofile-instr-use=<path> to -fprofile-instrument-use-path=<path>.
-fprofile-instr-use=<path> is now a driver only option.

In addition to decouple the cc1 option from the driver level option, this patch
also enables IR level profile use. cc1 option handling now reads the profile
header and sets CodeGenOpt ProfileUse (valid values are {None, Clang, LLVM}
-- this is a common enum for -fprofile-instrument={}, for the profile
instrumentation), and invoke the pipeline to enable the respective PGO use pass.

Reviewers: silvas, davidxl

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

llvm-svn: 262515

Fix minor bug in test

llvm-svn: 262514

Use shallow clones in build-llvm.py.

Summary:
This makes cloning (and therefore the whole build) faster.
The checkout step goes from ~4m to ~30s on my host.

Reviewers: tfiala

Subscribers: lldb-commits

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

llvm-svn: 262513

Revert "Fix ASAN detected errors in code and test" (it was not meant to be committed yet)

This reverts commit 890bbccd600ba1eb050353d06a29650ad0f2eb95.

llvm-svn: 262512

Fix ASAN detected errors in code and test

llvm-svn: 262511

Add another test for the GlobalOpt change in r212079.

This is a test that Akira Hatanaka wrote to test GlobalOpt's handling of
aliases with GEP operands. David Majnemer independently made the same
change to GlobalOpt in r212079. Akira's test is a useful addition, so I'm
pulling it over from the llvm repo for Swift on GitHub.

llvm-svn: 262510

[libFuzzer] more trophies

llvm-svn: 262509

fix test from r262506

llvm-svn: 262508

[ARM] Merging 64-bit divmod lib calls into one

When div+rem calls on the same arguments are found, the ARM back-end merges the
two calls into one __aeabi_divmod call for up to 32-bits values. However,
for 64-bit values, which also have a lib call (__aeabi_ldivmod), it wasn't
merging the calls, and thus calling ldivmod twice and spilling the temporary
results, which generated pretty bad code.

This patch legalises 64-bit lib calls for divmod, so that now all the spilling
and the second call are gone. It also relaxes the DivRem combiner a bit on the
legal type check, since it was already checking for isLegalOrCustom on every
value, so the extra check for isTypeLegal was redundant.

This patch fixes PR17193 (and a long time FIXME in the tests).

llvm-svn: 262507

Serialize `#pragma detect_mismatch`.

This is like r262493, but for pragma detect_mismatch instead of pragma comment.
The two pragmas have similar behavior, so use the same approach for both.

llvm-svn: 262506

Revert "[X86] Elide references to _chkstk for dynamic allocas"

This reverts commit r262370.

It turns out there is code out there that does sequences of allocas
greater than 4K: http://crbug.com/591404

The goal of this change was to improve the code size of inalloca call
sequences, but we got tangled up in the mess of dynamic allocas.
Instead, we should come back later with a separate MI pass that uses
dominance to optimize the full sequence. This should also be able to
remove the often unneeded stacksave/stackrestore pairs around the call.

llvm-svn: 262505

ARM: Introduce conservative load/store optimization mode

Most of the time ARM has the CCR.UNALIGN_TRP bit set to false which
means that unaligned loads/stores do not trap and even extensive testing
will not catch these bugs. However the multi/double variants are not
affected by this bit and will still trap. In effect a more aggressive
load/store optimization will break existing (bad) code.

These bugs do not necessarily manifest in the broken code where the
misaligned pointer is formed but often later in perfectly legal code
where it is accessed. This means recompiling system libraries (which
have no alignment bugs) with a newer compiler will break existing
applications (with alignment bugs) that worked before.

So (under protest) I implemented this safe mode which limits the
formation of multi/double operations to cases that are not affected by
user code (stack operations like spills/reloads) or cases where the
normal operations trap anyway (floating point load/stores). It is
disabled by default.

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

llvm-svn: 262504

[libFuzzer] allow -fsanitize-coverage=0 (disables all coverage)

llvm-svn: 262503

Merge DarwinLdDriver and Driver.

Now that DarwinLdDriver is the only derived class of Driver.
This patch merges them and actually removed the class because
they can now just be non-member functions. This change simplifies
a common header, Driver.h.

http://reviews.llvm.org/D17788

llvm-svn: 262502

Use C++11 initializers for data members.

http://reviews.llvm.org/D17793

llvm-svn: 262501

SelectionDAG: Use correctly sized allocation functions for SDNodes

The placement new calls here were all calling the allocation function
in RecyclingAllocator/Recycler for SDNode, instead of the function for
the specific subclass we were constructing.

Since this particular allocator always overallocates it more or less
worked, but would hide what we're actually doing from any memory
tools. Also, if you tried to change this allocator so something like a
BumpPtrAllocator or MallocAllocator, the compiler would crash horribly
all the time.

Part of llvm.org/PR26808.

llvm-svn: 262500

[CUDA] Do not generate unnecessary runtime init code.

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

llvm-svn: 262499

[CUDA] Emit host-side 'shadows' for device-side global variables

... and register them with CUDA runtime.

This is needed for commonly used cudaMemcpy*() APIs that use address of
host-side shadow to access their counterparts on device side.

Fixes PR26340

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

llvm-svn: 262498

1Fix handling of undef in partial LTO.

llvm-svn: 262497

[AArch64] Enable non-leaf frame pointer elimination.

Summary:
This change enables frame pointer elimination in non-leaf functions.
The -fomit-frame-pointer option still needs to be used when compiling
via clang (or an equivalent method of not setting the
'no-frame-pointer-elim*' function attributes if generating llvm IR via
some other method) to take advantage of this optimization.

This change should be NFC when compiling via clang without
-fomit-frame-pointer.

Reviewers: t.p.northover

Subscribers: aemerson, rengolin, tberghammer, qcolombet, llvm-commits, danalbert, mcrosier, srhines

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

llvm-svn: 262495

[CMake] Add test-depends target to build dependencies of check-all

This is just another convenience target for bots to use. It enables isolation of building and testing.

llvm-svn: 262494

Serialize `#pragma comment`.

`#pragma comment` was handled by Sema calling a function on ASTConsumer, and
CodeGen then implementing this function and writing things to its output.

Instead, introduce a PragmaCommentDecl AST node and hang one off the
TranslationUnitDecl for every `#pragma comment` line, and then use the regular
serialization machinery. (Since PragmaCommentDecl has codegen relevance, it's
eagerly deserialized.)

http://reviews.llvm.org/D17799

llvm-svn: 262493

LTO: Use the correct relocation model.

llvm-svn: 262492

[cmake] Check the compiler version first

Otherwise users get messages from CheckAtomic about missing libatomic
instead of a sensible message that says "use GCC 4.7 or newer".

I structured the change along the lines of HandleLLVMStdlib.cmake, so
that the standalone build of Clang still gets the compiler version
check.

Reviewers: beanz

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

llvm-svn: 262491

[AA] Hoist the logic to reformulate various AA queries in terms of other
parts of the AA interface out of the base class of every single AA
result object.

Because this logic reformulates the query in terms of some other aspect
of the API, it would easily cause O(n^2) query patterns in alias
analysis. These could in turn be magnified further based on the number
of call arguments, and then further based on the number of AA queries
made for a particular call. This ended up causing problems for Rust that
were actually noticable enough to get a bug (PR26564) and probably other
places as well.

When originally re-working the AA infrastructure, the desire was to
regularize the pattern of refinement without losing any generality.
While I think it was successful, that is clearly proving to be too
costly. And the cost is needless: we gain no actual improvement for this
generality of making a direct query to tbaa actually be able to
re-use some other alias analysis's refinement logic for one of the other
APIs, or some such. In short, this is entirely wasted work.

To the extent possible, delegation to other API surfaces should be done
at the aggregation layer so that we can avoid re-walking the
aggregation. In fact, this significantly simplifies the logic as we no
longer need to smuggle the aggregation layer into each alias analysis
(or the TargetLibraryInfo into each alias analysis just so we can form
argument memory locations!).

However, we also have some delegation logic inside of BasicAA and some
of it even makes sense. When the delegation logic is baking in specific
knowledge of aliasing properties of the LLVM IR, as opposed to simply
reformulating the query to utilize a different alias analysis interface
entry point, it makes a lot of sense to restrict that logic to
a different layer such as BasicAA. So one aspect of the delegation that
was in every AA base class is that when we don't have operand bundles,
we re-use function AA results as a fallback for callsite alias results.
This relies on the IR properties of calls and functions w.r.t. aliasing,
and so seems a better fit to BasicAA. I've lifted the logic up to that
point where it seems to be a natural fit. This still does a bit of
redundant work (we query function attributes twice, once via the
callsite and once via the function AA query) but it is *exactly* twice
here, no more.

The end result is that all of the delegation logic is hoisted out of the
base class and into either the aggregation layer when it is a pure
retargeting to a different API surface, or into BasicAA when it relies
on the IR's aliasing properties. This should fix the quadratic query
pattern reported in PR26564, although I don't have a stand-alone test
case to reproduce it.

It also seems general goodness. Now the numerous AAs that don't need
target library info don't carry it around and depend on it. I think
I can even rip out the general access to the aggregation layer and only
expose that in BasicAA as it is the only place where we re-query in that
manner.

However, this is a non-trivial change to the AA infrastructure so I want
to get some additional eyes on this before it lands. Sadly, it can't
wait long because we should really cherry pick this into 3.8 if we're
going to go this route.

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

llvm-svn: 262490

Handle comdat in LTO.

llvm-svn: 262489

Fix: Add pass manager barrier.

The LNT test suite with -polly-process-unprofitable
-polly-position=before-vectorizer currenty fails 59 tests. With this
barrier added, only 16 keep failing. This is probably because Polly's
code generation currently does not correctly preserve all analyses it
promised to preserve. Temporarily add this barrier until further
investigation.

llvm-svn: 262488

test/Driver/cl-pch-errorhandling.cpp: Copy input file to a temporary
location as we cannot assume the location of the input file to be
writable.

llvm-svn: 262487

[X86][SSSE3] Added combine test for unary shuffle (pshufb) only referencing elements from one of the inputs of a binary shuffle (punpcklbw)

llvm-svn: 262486

Fix BUILD_SHARED_LIBS build.

llvm-svn: 262485

[clang-tidy] Fix an assertion failure of "SLocEntry::getExpansion()" when IncludeInserter handles macro header file.

Summary: Also Fixes PR24749.

Reviewers: alexfh

Subscribers: cfe-commits

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

llvm-svn: 262484

[TSAN] Fix test java_race_pc

Incremented the pc for each architecture in accordance with StackTrace:GetPreviousInstructionPC

Reviewers: samsonov, dvyukov
Subscribers: llvm-commits, mohit.bhakkad, jaydeep
Differential: http://reviews.llvm.org/D17802
llvm-svn: 262483

Upgrade the arm/thumb architecture used by the disassembler

Previously we were using thumbv7 and armv8.1a what ended up showing a
few undefined instruction when disassembling code. This CL update the
architectures used to armv8.2a and thumbv8.2a (newest available) so we
display all instruction in the disassambly.

llvm-svn: 262482

[CLANG] [AVX512] [BUILTIN] Adding PSRA{W|WI}{128|256|512}.

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

llvm-svn: 262481

[LLVM][AVX512]PSRAWI Change imm8 to int.

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

llvm-svn: 262480

Revert "[RT] Make tsan tests more portable"

This reverts commit r262476, as it broken the AArch64 VMA42 buildbot.

llvm-svn: 262479

[X86][SSE] Lower 128-bit MOVDDUP with existing VBROADCAST mechanisms

We have a number of useful lowering strategies for VBROADCAST instructions (both from memory and register element 0) which the 128-bit form of the MOVDDUP instruction can make use of.

This patch tweaks lowerVectorShuffleAsBroadcast to enable it to broadcast 2f64 args using MOVDDUP as well.

It does require a slight tweak to the lowerVectorShuffleAsBroadcast mechanism as the existing MOVDDUP lowering uses isShuffleEquivalent which can match binary shuffles that can lower to (unary) broadcasts.

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

llvm-svn: 262478

Revert "[AMDGPU] table-driven parser/printer for amd_kernel_code_t structure fields"

Build failure with clang.

llvm-svn: 262477

[RT] Make tsan tests more portable

by avoiding potential races when scanning stdout and stderr output.

Patch by Maxim Kuvyrkov.

llvm-svn: 262476

Revert "[AMDGPU] Using table-driven amd_kernel_code_t field parser in assembler."

Build failure with clang.

llvm-svn: 262475

[AMDGPU] Using table-driven amd_kernel_code_t field parser in assembler.

complementary patch to table-driven amd_kernel_code_t field parser/printer utility. lit tests passed.

Patch by: Valery Pykhtin

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

llvm-svn: 262474

[AMDGPU] table-driven parser/printer for amd_kernel_code_t structure fields

This is going to be used in .hsatext disassembler and can be used
in current assembler parser (lit tests passed on parsing).
Code using this helpers isn't included in this patch.

Benefits:

unified approach
fast field name lookup on parsing
Later I would like to enhance some of the field naming/syntax using this code.

Patch by: Valery Pykhtin

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

llvm-svn: 262473

libfuzzer: fix compiler warnings

- unused sigaction/setitimer result (used in assert)
- unchecked fscanf return value
- signed/unsigned comparison

llvm-svn: 262472

[CLANG] [AVX512] [BUILTIN] Adding PSRAV

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

llvm-svn: 262471

[clang-tidy] Make 'modernize-pass-by-value' fix work on header files.

Reviewers: alexfh

Subscribers: jbcoe, cfe-commits

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

llvm-svn: 262470

[test/vptr-non-unique-typeinfo] Address Samsonov's post-commit review

Reviewers: samsonov

Subscribers: llvm-commits

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

llvm-svn: 262469

[X86] Remove unnecessary call to isReg from emitter's DestMem handling for VEX prefix. The operand is always a register. NFC

llvm-svn: 262468

[X86] Make X86MCCodeEmitter::DetermineREXPrefix locate operands more like how VEX prefix handling does.

llvm-svn: 262467

[Sema] PR26444 fix crash when alignment value is >= 2**16

Sema allows max values up to 2**28, use unsigned instead of unsiged
short to hold values that large.

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

Patch by Don Hinton!

llvm-svn: 262466

[X86] Permit reading of the FLAGS register without it being previously defined

We modeled the RDFLAGS{32,64} operations as "using" {E,R}FLAGS.
While technically correct, this is not be desirable for folks who want
to examine aspects of the FLAGS register which are not related to
computation like whether or not CPUID is a valid instruction.

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

llvm-svn: 262465

[X86] Remove assertion I accidentally left in.

llvm-svn: 262464

[modules] addHeaderInclude() can't fail.

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

llvm-svn: 262463

[X86] Be more structured about how we capture the register number when it is encoded in bits 7:4 of the immediate.

For some instructions the register is not the last operand and the immediate handling had to detect this and hardcode the index to find it. It also required CurOp to be pointing at the last operand handled in the Form switch whereas for any instruction it would be pointing at the next operand.

Now we just capture the value in the Form switch when we know exactly where it is and the CurOp pointer can behave normally.

llvm-svn: 262462

[ELF] Fix reading of PC values of FDEs

The patch fixes two related problems:
- If CIE augmentation string has 'L' token the CIE contains a byte
  defines LSDA encoding. We should skip this byte in `getFdeEncoding`
  routine. Before this fix we do not skip it and if the next token
  is 'R' treat this byte as FDE encoding.
- FDE encoding format has separate flags e.g. DW_EH_PE_pcrel for
  definition of relative pointers. We should add .eh_frame address to
  the PC value iif the DW_EH_PE_pcrel is specified.

http://www.airs.com/blog/archives/460

There is one more not fixed problem in this code. If PC value is encoded
using signed relative format e.g. DW_EH_PE_sdata4 | DW_EH_PE_pcrel we
should sign extend result of read32 to perform calculation correctly.
I am going to fix that in a separate patch.

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

llvm-svn: 262461

[OPENMP 4.5] Codegen for data members in 'reduction' clause.

OpenMP 4.5 allows to privatize non-static data members of current class
in non-static member functions. Patch supports codegen for non-static
data members in 'reduction' clauses.

llvm-svn: 262460

[SCEV] Minor naming, braces cleanup; NFC

llvm-svn: 262459

[X86] Use MCPhysReg and uint16_t for static arrays of registers and opcodes respectively should reduce size tiny bit. NFC

llvm-svn: 262458

AMDGPU: Fix bug 26659.

Fix checking the same instruction twice instead of the
second branch that uses vccz. I don't think this matters
currently because s_branch_vccnz is always used currently.

llvm-svn: 262457

AMDGPU: Cleanup suggested in bug 23960

llvm-svn: 262456

Bug 20810: Use report_fatal_error instead of unreachable

llvm-svn: 262455

Add a comment with a rational for the unusual code structure

llvm-svn: 262454

Qualify getRangeForAffineAR with this-> for MSVC

llvm-svn: 262453

Attempt to fix ASAN failure in a MemorySSA test.

llvm-svn: 262452

Perturb code in an attempt to appease MSVC

For some reason MSVC seems to think I'm calling getConstant() from a
static context.  Try to avoid this issue by explicitly specifying
'this->' (though I'm not confident that this will actually work).

llvm-svn: 262451

Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; other minor fixes.

llvm-svn: 262450

More code permutation to appease MSVC

llvm-svn: 262449

Remove "auto" to appease the MSVC bots

llvm-svn: 262448

Use C++11 initializers for data members.

llvm-svn: 262447

DAGCombiner: Make sure an integer is being truncated

llvm-svn: 262446

Remove more dead code.

llvm-svn: 262445

Remove default implementations that are always overridden by subclasses.

llvm-svn: 262444

Remove more dead code.

llvm-svn: 262443

Add a few dllimport/dllexport tests.  NFC

Summary:
This change just adds tests for some corner cases of dllimport/dllexport,
primarily for some static methods.

We plan to enable dllimport/dllexport support for the PS4, and these
additional tests are for points we previously were testing internally.

-Warren Ristow
SN Systems - Sony Computer Entertainment Group

Reviewers: rnk

Subscribers: silvas

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

llvm-svn: 262442

Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; other minor fixes.

llvm-svn: 262441

revert r262424 because there's a *clang test* for AArch64 that checks -O3 asm output
that is broken by this change

llvm-svn: 262440

Fix SHARED_LIBS build

llvm-svn: 262439

[SCEV] Make getRange smarter around selects

Have ScalarEvolution::getRange re-consider cases like "{C?A:B,+,C?P:Q}"
by factoring out "C" and computing RangeOf{A,+,P} union RangeOf({B,+,Q})
instead.

The latter can be easier to compute precisely in cases like
"{C?0:N,+,C?1:-1}" N is the backedge taken count of the loop; since in
such cases the latter form simplifies to [0,N+1) union [0,N+1).

llvm-svn: 262438

[SCEV] Extract out a getRangeForAffineAR; NFC

Pure code-motion change.  Will be used later in making getRange more clever.

llvm-svn: 262437

Remove dead code.

llvm-svn: 262436

Remove remaining files of Core.

llvm-svn: 262435