[Hexagon] Adding accumulating add/sub, doubleword logic-not variants, doubleword bitfield extract, word parity, accumulating multiplies with saturation.

llvm-svn: 225024

This patch updates the list of supported platforms to include
Windows, and also provides some detailed getting started instructions
for building LLDB on Windows.

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

llvm-svn: 225023

llvm-svn: 225022

llvm-svn: 225021

Too many different comment characters - instead of trying to account for
them all, instead disable the comments and just check for end-of-line
instead.

llvm-svn: 225020

llvm-svn: 225019

llvm-svn: 225018

llvm-svn: 225017

llvm-svn: 225016

llvm-svn: 225015

This fixes the DSO build for now. Eventually we should develop some
other mechanism to make this work correctly with DSOs.

llvm-svn: 225014

Unify the component handling for compiler-rt.  The components are regularly
named, built up from:

  ${LIBRARY_PREFIX}clang_rt.${component}-${arch}[-${environment}]${LIBRARY_SUFFIX}

Unify the handling for all the various components, into a single path to link
against the various components in a number of places.  This reduces duplication
of the clang_rt library name construction logic.

llvm-svn: 225013

Fixup some whitespace/style issues.  NFC.

llvm-svn: 225012

GCC does this for non-zero discriminators and since GCC doesn't produce
column info, that was the only place it comes up there. For LLVM, since
we can emit discriminators and/or column info, it makes more sense to
invert the condition and just test for changes in line number.

This should resolve at least some of the GDB 7.5 test suite failures
created by recent Clang changes that increase the location fidelity
(which, since Clang defaults to including column info on Linux by
default created a bunch of cases that confused GDB).

In theory we could do this better/differently by grouping actual source
statements together in a similar manner to the way lexical scopes are
handled but given that GDB isn't really in a position to consume that (&
users are probably somewhat used to different lines being different
'statements') this seems the safest and cheapest change. (I'm concerned
that doing this 'right' would bloat the debugloc data even further -
something Duncan's working hard to address)

llvm-svn: 225011

llvm-svn: 225010

llvm-svn: 225009

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

llvm-svn: 225008

llvm-svn: 225007

llvm-svn: 225006

llvm-svn: 225005

llvm-svn: 225004

Under the large code model, we cannot assume that __morestack lives within
2^31 bytes of the call site, so we cannot use pc-relative addressing. We
cannot perform the call via a temporary register, as the rax register may
be used to store the static chain, and all other suitable registers may be
either callee-save or used for parameter passing. We cannot use the stack
at this point either because __morestack manipulates the stack directly.

To avoid these issues, perform an indirect call via a read-only memory
location containing the address.

This solution is not perfect, as it assumes that the .rodata section
is laid out within 2^31 bytes of each function body, but this seems to
be sufficient for JIT.

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

llvm-svn: 225003

[asan] add flag coverage_pcs. When false, the coverage is not dumped as PCs. Useful e.g. if the user only needs coverage is bitset

llvm-svn: 225002

(recommitting as the Clang patch is back in with the latest fix -
hopefully it sticks)

llvm-svn: 225001

Originally committed in r224385 and reverted in r224441 due to concerns
this change might've introduced a crash. Turns out this change fixes the
crash introduced by one of my earlier more specific location handling
changes (those specific fixes are reverted by this patch, in favor of
the more general solution).

Recommitted in r224941 and reverted in r224970 after it caused a crash
when building compiler-rt. Looks to be due to this change zeroing out
the debug location when emitting default arguments (which were meant to
inherit their outer expression's location) thus creating call
instructions without locations - these create problems for inlining and
must not be created. That is fixed and tested in this version of the
change.

Original commit message:

This is a more scalable (fixed in mostly one place, rather than many
places that will need constant improvement/maintenance) solution to
several commits I've made recently to increase source fidelity for
subexpressions.

This resetting had to be done at the DebugLoc level (not the
SourceLocation level) to preserve scoping information (if the resetting
was done with CGDebugInfo::EmitLocation, it would've caused the tail end
of an expression's codegen to end up in a potentially different scope
than the start, even though it was at the same source location). The
drawback to this is that it might leave CGDebugInfo out of sync. Ideally
CGDebugInfo shouldn't have a duplicate sense of the current
SourceLocation, but for now it seems it does... - I don't think I'm
going to tackle removing that just now.

I expect this'll probably cause some more buildbot fallout & I'll
investigate that as it comes up.

Also these sort of improvements might be starting to show a weakness/bug
in LLVM's line table handling: we don't correctly emit is_stmt for
statements, we just put it on every line table entry. This means one
statement split over multiple lines appears as multiple 'statements' and
two statements on one line (without column info) are treated as one
statement.

I don't think we have any IR representation of statements that would
help us distinguish these cases and identify the beginning of each
statement - so that might be something we need to add (possibly to the
lexical scope chain - a scope for each statement). This does cause some
problems for GDB and possibly other DWARF consumers.

llvm-svn: 225000

llvm-svn: 224999

If a linker directive is already quoted, don't try to quote it again, otherwise it creates a mess.
This pops up in places like:
#pragma comment(linker,"\"/foo bar'\"")

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

llvm-svn: 224998

llvm-svn: 224997

Unlike Unices, Windows does not use a library prefix.  Use the traditional
naming scheme even for Windows itanium environments.  This makes the builtins
behave more like the sanitisers as well.

llvm-svn: 224996

All the other get*Opts have both versions.

llvm-svn: 224995

llvm-svn: 224994

This function's implementation lives in libgcc, a static library, so we need
to expose it explicitly, like the other such functions.

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

llvm-svn: 224993

llvm-svn: 224992

[Hexagon] Adding compare byte/halfword reg-reg/reg-imm forms.  Adding compare to general register reg-imm form.

llvm-svn: 224991

Following changes were done.
1. Remove the extra line after -exec-run.
2. Remove check for prompt.
3. Remove 'quit' command. 

Initial patch was contributed by ki.stfu@gmail.com.

llvm-svn: 224990

[Hexagon] Updating constant extender def, adding alu-not instructions, compare to general register, and inverted compares.

llvm-svn: 224989

llvm-svn: 224988

llvm-svn: 224987

No functional changes.

llvm-svn: 224986

In an assembly expression like

bar:
.long L0 + 1

the intended semantics is that bar will contain a pointer one byte past L0.

In sections that are merged by content (strings, 4 byte constants, etc), a
single position in the section doesn't give the linker enough information.
For example, it would not be able to tell a relocation must point to the
end of a string, since that would look just like the start of the next.

The solution used in ELF to use relocation with symbols if there is a non-zero
addend.

In MachO before this patch we would just keep all symbols in some sections.

This would miss some cases (only cstrings on x86_64 were implemented) and was
inefficient since most relocations have an addend of 0 and can be represented
without the symbol.

This patch implements the non-zero addend logic for MachO too.

llvm-svn: 224985