Summary:
Cross-compilation uses recursive cmake invocations to build native host
tools.  These recursive invocations only forward a fixed set of
variables/options, since the native environment is generally the default.
This change adds -DLLVM_TARGET_IS_CROSSCOMPILE_HOST=TRUE to the recursive
cmake invocations, so that cmake files can distinguish these recursive
invocations from top-level ones, which can explain why expected options
are unset.

LLILC will use this to avoid trying to generate its build rules in the
crosscompile native host target (where it is not needed), which would fail
if attempted because LLILC requires a cmake variable passed on the command
line, which is not forwarded in the recursive invocation.

Reviewers: rnk, beanz

Subscribers: llvm-commits

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

llvm-svn: 247151

llvm-svn: 247150

  vextracti64x4 ,vextracti64x2, vextracti32x8, vextracti32x4, vextractf64x4, vextractf64x2, vextractf32x8, vextractf32x4
Added tests for intrinsics and encoding.

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

llvm-svn: 247149

llvm-svn: 247148

  The support for pointer expressions is broken as it can only handle
  some patterns in the IslExprBuilder. We should to treat pointers in
  expressions the same as integers at some point and revert this patch.

llvm-svn: 247147

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

llvm-svn: 247146

llvm-svn: 247145

Patch by Xan López!

llvm-svn: 247144

Due to LLDB or test race conditions these tests do not pass
consistently.

llvm.org/pr15037
llvm.org/pr19310
llvm.org/pr22611

llvm-svn: 247143

Add a custom makefile rule to generate lib/External/isl/gitversion.h
from GIT_HEAD_ID and trigger it using BULIT_SOURCES to ensure the file
exists before compilation starts.

The latest ISL creates gitversion.h from Makefile.am only, instead also
from configure.ac in previous version. While the Polly build invokes
configure, it does not invoke ISL's make such that the file was missing.

Invoking ISL's make would come with additional problems such as
triggering automake because of not preserved file time stamps.
Re-running automake might not be successful on other system
configurations for instance because it was preconfigured without
--with-clang option.

llvm-svn: 247142

The test is hitting an assertion in Clang.  This is an extension of
r246766.

llvm.org/pr24691

llvm-svn: 247141

We called a variable ExitCount, stored the backedge count in it, then redefined it to be the exit count again.

llvm-svn: 247140

Predicating stores requires creating extra blocks. It's much cleaner if we do this in one pass instead of mutating the CFG while writing vector instructions.

Besides which we can make use of helper functions to update domtree for us, reducing the work we need to do.

llvm-svn: 247139

The tests in test/CodeGen/arm-target-features.c are currently
passing but warning messages are suppressed. These tests are now
synchronized with the corresponding changes in Target Parser.

This patch will fix the regressions in clang caused by r247136

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

llvm-svn: 247138

llvm-svn: 247137

Removed "cortex-r5f" and "cortex-m4f" from Target Parser, sinced they are
unknown cpu names for llvm and clang. Also updated default FPUs for R5 and M4
accordingly.

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

Change-Id: Ib81c7216521a361d8ee1296e4b6a2aa00bd479c5
llvm-svn: 247136

llvm-svn: 247135

Patch by Nitesh Jain

Reviewers: clayborg, ovyalov.
Subscribers: jaydeep, bhushan, mohit.bhakkad, sagar, nitesh.jain, lldb-commits.
Differential Revision: http://reviews.llvm.org/D12671

llvm-svn: 247134

In some special case (e.g. signal handlers, hand written assembly) it is
valid to have 2 stack frame with the same CFA value. This CL change the
looping stack detection code to report a loop only if at least 3
consecutive frames have the same CFA.

Differential revision: http://reviews.llvm.org/D12699

llvm-svn: 247133

* Create new dwo symbol file class
* Add handling for .dwo sections
* Change indexes in SymbolFileDWARF to store compile unit offset next to
  DIE offset
* Propagate queries from dwarf compile unit to the dwo compile unit
  where applicable

Differential revision: http://reviews.llvm.org/D12291

llvm-svn: 247132

* Remove some unused code
* Remove usage of DWARFDebugInfoEntry::Attributes where usage isn't
  reasonable
* Cleanup DWARFMappedHash with separating it to header and implementation
  file and fixing the visibility of the functions

Differential revision: http://reviews.llvm.org/D12374

llvm-svn: 247131

The dwo files are generated when the tests run with split dwarf info.

llvm-svn: 247130

Reviewers: clayborg.
Subscribers: jaydeep, bhushan, sagar, nitesh.jain, lldb-commits.
Differential Revision: http://reviews.llvm.org/D12670

llvm-svn: 247129

Summary:
One of the vector splitting paths for extract_vector_elt tries to lower:
    define i1 @via_stack_bug(i8 signext %idx) {
      %1 = extractelement <2 x i1> <i1 false, i1 true>, i8 %idx
      ret i1 %1
    }
to:
    define i1 @via_stack_bug(i8 signext %idx) {
      %base = alloca <2 x i1>
      store <2 x i1> <i1 false, i1 true>, <2 x i1>* %base
      %2 = getelementptr <2 x i1>, <2 x i1>* %base, i32 %idx
      %3 = load i1, i1* %2
      ret i1 %3
    }
However, the elements of <2 x i1> are not byte-addressible. The result of this
is that the getelementptr expands to '%base + %idx * (1 / 8)' which simplifies
to '%base + %idx * 0', and then simply '%base' causing all values of %idx to
extract element zero.

This commit fixes this by promoting the vector elements of <8-bits to i8 before
splitting the vector.

This fixes a number of test failures in pocl.

Reviewers: pekka.jaaskelainen

Subscribers: pekka.jaaskelainen, llvm-commits

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

llvm-svn: 247128

nothing broke.

llvm-svn: 247127

Not all users of our IslNodeBuilder will attach scheduling information to the
AST in the same way IslAstInfo is doing it today. By going through a virtual
function when extracting the schedule of an AST node other users can provide
their own functions for extract scheduling information in case they attach
scheduling information in a different way to the AST nodes.

No functional change for Polly itself intended.

llvm-svn: 247126

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

llvm-svn: 247125

Summary:
When lldb is processing a location containing DW_OP_piece, the result is being
stored in the 'pieces' variable. The location is popped from the 'stack' variable.
So this check to see that 'stack' is not empty was invalid and caused the pieces
after the first to not get processed.

I am working on an architecture which has 16-bit and 8-bit registers. So this
problem was quite easy to see. But I was able to re-produce this issue on x86
too with long long variable and compiling woth -m32. It resulted in following
location list.
00000014 08048496 080484b5 (DW_OP_reg6 (esi); DW_OP_piece: 4; DW_OP_reg7 (edi); DW_OP_piece: 4)

and lldb was only showing the contents of first register when I evaluated the
variable as it does not process the 2nd piece due to this check.

Reviewers: clayborg, aprantl

Subscribers: lldb-commits

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

llvm-svn: 247124

Broken by r247074. Should include an assembler test,
but the assembler is currently broken for VOP3b apparently.

llvm-svn: 247123

IRCE was just using INITIALIZE_PASS(), which is incorrect.

llvm-svn: 247122

qXfer:features:read:target.xml packet, or via the
plugin.process.gdb-remote.target-definition-file setting, if the
register definition doesn't give us eh_frame or DWARF register
numbers for that register, try to get that information from the ABI
plugin.

The DWARF/eh_frame register numbers are defined in the ABI
standardization documents - so getting this from the ABI plugin is
reasonable.  There's little value in having the remote stub inform
us of this generic information, as long as we can all agree on the
names of the registers.

There's some additional information we could get from the ABI.  For
instance, on ABIs where function arguments are passed in registers,
lldb defines alternate names like "arg1", "arg2", "arg3" for these
registers so they can be referred to that way by the user.  We could
get this from the ABI if the remote stub doesn't provide that.  That
may be something worth doing in the future - but for now, I'm keeping
this a little more minimal.

Thinking about this, what we want/need from the remote stub at a
minimum are:

 1. The names of the register
 2. The number that the stub will use to refer to the register with
    the p/P packets and in the ? response packets (T/S) where 
    expedited register values are provided
 3. The size of the register in bytes
   
(nice to have, to remove any doubt)
 4. The offset of the register in the g/G packet if we're going to
    use that for reading/writing registers.

debugserver traditionally provides a lot more information in
addition to this via the qRegisterInfo packet, and debugserver 
augments its response to the qXfer:features:read:target.xml
query to include this information.  Including:

DWARF regnum, eh_frame regnum, stabs regnum, encoding (ieee754,
Uint, Vector, Sint), format (hex, unsigned, pointer, vectorof*,
float), registers that should be marked as invalid if this 
register is modified, and registers that contain this register.

We might want to get all of this from the ABI - I'm not convinced
that it makes sense for the remote stub to provide any of these 
details, as long as the ABI and remote stub can agree on register
names.

Anyway, start with eh_frame and DWARF coming from the ABI if 
they're not provided by the remote stub.  We can look at doing
more in the future.

<rdar://problem/22566585> 

llvm-svn: 247121

When lldb receives a gdb-remote protocol packet that has
nonprintable characters, it will print the packet in
gdb-remote logging with binary-hex encoding so we don't 
dump random 8-bit characters into the packet log.

I'm changing this check to allow whitespace characters
(newlines, linefeeds, tabs) to be printed if those are
the only non-printable characters in the packet. 

This is primarily to get the response to the 
qXfer:features:read:target.xml packet to show up in the
packet logs in human readable form.  Right now we just
get a dozen kilobytes of hex-ascii and it's hard to 
figure out what register number scheme is being used.

llvm-svn: 247120

llvm-svn: 247119

llvm-svn: 247118

Fix a bug introduced in r246985 which causes assertion when generating
vld1_lane.

llvm-svn: 247117

Summary: NetBSD is a free, fast, secure, and highly portable Unix-like Open Source operating system.

Reviewers: joerg, sas

Subscribers: sas, emaste, lldb-commits

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

Change by Kamil Rytarowski <n54@gmx.com>

llvm-svn: 247116

Reviewers: joerg, sas

Subscribers: labath, lldb-commits

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

Change by Kamil Rytarowski <n54@gmx.com>

llvm-svn: 247115

Summary: Build warning caught on NetBSD.

Reviewers: joerg, sas

Subscribers: lldb-commits

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

Change by Kamil Rytarowski <n54@gmx.com>

llvm-svn: 247114

Currently this hits an assert that extload should
always be supported, which assumes integer extloads.

This moves a hack out of SI's argument lowering and
is covered by existing tests.

llvm-svn: 247113

Data formatter candidate matches can be generated in a number of ways; language-based dynamic type discovery being one of them (for instance, this is what takes an 'id' and discovers that it truly is an __NSArrayI, so it should probably use the NSArray formatter)

This used to be hardcoded in the FormatManager, but in a pluginized world that is not the right way to go

So, move this step to the Language plugin such that appropriate language plugins for a type get a say about adding candidates to the formatters lookup tables

llvm-svn: 247112