llvm-svn: 145020

generate any reasonable depfile if a header is missing.

llvm-svn: 145019

output files that are valid regardless of whether the compilation
succeeded or failed (but not if we crash).  Add depfiles to the
failure result file list.

llvm-svn: 145018

This saves us from re-creating the symlink on every build even if we
didn't rebuild clang.

llvm-svn: 145017

Fixes PR4777.

llvm-svn: 145015

llvm-svn: 145014

Suggested in code review by Eli.

That code in InstCombine looks kinda suspicious.

llvm-svn: 145013

from Jason Haslam!

llvm-svn: 145012

llvm-svn: 145011

properly account for the *global* probability of the edge being taken.
This manifested as a very large number of unconditional branches to
blocks being merged against the CFG even though they weren't
particularly hot within the CFG.

The fix is to check whether the edge being merged is both locally hot
relative to other successors for the source block, and globally hot
compared to other (unmerged) predecessors of the destination block.

This introduces a new crasher on GCC single-source, but it's currently
behind a flag, and Ben has offered to work on the reduction. =]

llvm-svn: 145010

llvm-svn: 145009

llvm-svn: 145008

setFlags doesn't modify its arguments.

llvm-svn: 145007

is actually being tested. Also add some FileCheck goodness to much more
carefully ensure that the result is the desired result. Before this test
would only have failed through an assert failure if the underlying fix
were reverted.

Also, add some weight metadata and a comment explaining exactly what is
going on to a trick section of the test case. Originally, we were
getting very unlucky and trying to form a block chain that isn't
actually profitable. I'm working on a fix to avoid forming these
unprofitable chains, and that would also have masked any failure from
this test case. The easy solution is to add some metadata that makes it
*really* profitable to form the bad chain here.

llvm-svn: 145006

Add code for lowering v32i8 shifts by a splat to AVX2 immediate shift instructions. Remove 256-bit splat handling from LowerShift as it was already handled by PerformShiftCombine.

llvm-svn: 145005

llvm-svn: 145004

Remove some of the special classes that worked around an old tablegen limitation of not being able to remove redundant bitconverts from patterns.

llvm-svn: 145003

llvm-svn: 145002

llvm-svn: 145001

llvm-svn: 145000

llvm-svn: 144999

llvm-svn: 144995

formation phase and into the initial walk of the basic blocks. We
essentially pre-merge all blocks where unanalyzable fallthrough exists,
as we won't be able to update the terminators effectively after any
reorderings. This is quite a bit more principled as there may be CFGs
where the second half of the unanalyzable pair has some analyzable
predecessor that gets placed first. Then it may get placed next,
implicitly breaking the unanalyzable branch even though we never even
looked at the part that isn't analyzable. I've included a test case that
triggers this (thanks Benjamin yet again!), and I'm hoping to synthesize
some more general ones as I dig into related issues.

Also, to make this new scheme work we have to be able to handle branches
into the middle of a chain, so add this check. We always fallback on the
incoming ordering.

Finally, this starts to really underscore a known limitation of the
current implementation -- we don't consider broken predecessors when
merging successors. This can caused major missed opportunities, and is
something I'm planning on looking at next (modulo more bug reports).

llvm-svn: 144994

- With the current implementation of sys::Program this always printed "2".
- The command execution code will output the right number anyway (including the signal name).

llvm-svn: 144993

llvm-svn: 144992

constructors go below public member functions?

llvm-svn: 144991

llvm-svn: 144990

Synthesize SSSE3/AVX 128-bit horizontal integer add/sub instructions from add/sub of appropriate shuffle vectors.

llvm-svn: 144989

llvm-svn: 144988

llvm-svn: 144987

llvm-svn: 144986

llvm-svn: 144985

several patches.  These patches fix a problem
where templated types were not being completed the
first time they were used, and fix a variety of
minor issues I discovered while fixing that problem.

One of the previous local patches was resolved in
the most recent Clang, so I removed it.  The others
will be removed in due course.

llvm-svn: 144984

1 - the DIE collections no longer have the NULL tags which saves up to 25%
    of the memory on typical C++ code
2 - faster parsing by not having to run the SetDIERelations() function anymore
    it is done when parsing the DWARF very efficiently.

llvm-svn: 144983

templates is properly complete (though still
empty).

llvm-svn: 144982

Handle stepping through a trampoline where the jump target is calculated a runtime - and so doesn't match
the name of the PLT entry.  This solution assumes a naming convention agreed upon by us and the system folks,
and isn't general.  The general solution requires actually finding & calling the resolver function if it
hasn't been called yet.  That's more tricky.

llvm-svn: 144981

llvm-svn: 144980

llvm-svn: 144977

from a process and hooked it up to the new packet that was recently added
to our GDB remote executable named debugserver. Now Process has the following
new calls:

virtual Error
Process::GetMemoryRegionInfo (lldb::addr_t load_addr, MemoryRegionInfo &range_info);

virtual uint32_t
GetLoadAddressPermissions (lldb::addr_t load_addr);

Only the first one needs to be implemented by subclasses that can add this
support.

Cleaned up the way the new packet was implemented in debugserver to be more
useful as an API inside debugserver. Also found an error where finding a region
for an address actually will pick up the next region that follows the address
in the query so we also need ot make sure that the address we requested the
region for falls into the region that gets returned.

llvm-svn: 144976

we say that the vectors of DWARFDebugInfoEntry objects were the highest on the
the list. 

With these changes we cut our memory usage by 40%!!! I did this by reducing
the size of the DWARFDebugInfoEntry from a previous:

uint32_t offset
uint32_t parent_idx
uint32_t sibling_idx
Abbrev * abbrev_ptr

which was 20 bytes, but rounded up to 24 bytes due to alignment. Now we have:

uint32_t offset
uint32_t parent_idx
uint32_t sibling_idx
uint32_t abbr_idx:15,       // 32767 possible abbreviation codes
         has_children:1,    // 0 = no children, 1 = has children
         tag:16;            // DW_TAG_XXX value

This gets us down to 16 bytes per DIE. I tested some VERY large DWARF files
(900MB) and found there were only ~700 unique abbreviations, so 32767 should
be enough for any sane compiler. If it isn't there are built in assertions
that will fire off and tell us.

llvm-svn: 144975