be unused.

llvm-svn: 244014

llvm-svn: 244013

it anymore.

llvm-svn: 244012

llvm-svn: 244011

llvm-svn: 244009

llvm-svn: 244008

llvm-svn: 244007

llvm-svn: 244006

llvm-svn: 244005

llvm-svn: 244004

llvm-svn: 244003

llvm-svn: 244002

llvm-svn: 244001

llvm-svn: 244000

llvm-svn: 243999

As documented in the LLVM Coding Standards, indeed MSVC incorrectly asserts 
on this in Debug mode. This happens when building clang with Visual C++ and
-triple i686-pc-windows-gnu on these clang regression tests:

 clang/test/CodeGen/2011-03-08-ZeroFieldUnionInitializer.c
 clang/test/CodeGen/empty-union-init.c

llvm-svn: 243996

std::copy does not work for non-trivially copyable classes when we're
copying into uninitialized memory.

llvm-svn: 243995

Create wrapper methods in the Function class for the OptimizeForSize and MinSize
attributes. We want to hide the logic of "or'ing" them together when optimizing
just for size (-Os).

Currently, we are not consistent about this and rely on a front-end to always set
OptimizeForSize (-Os) if MinSize (-Oz) is on. Thus, there are 18 FIXME changes here
that should be added as follow-on patches with regression tests.

This patch is NFC-intended: it just replaces existing direct accesses of the attributes
by the equivalent wrapper call.

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

llvm-svn: 243994

The writer is still hard coded to 64 bits le, but with this we can test for
invalid ELF files.

llvm-svn: 243993

llvm-svn: 243992

Begin adapting some of the implemented PPC64 relocations for PPC32 (with a
test case).

Patch by Pierre-Andre Saulais!

llvm-svn: 243991

In the commentary for D11660, I wasn't sure if it was alright to create new
integer machine instructions without also creating the implicit EFLAGS operand. 
From what I can see, the implicit operand is always created by the MachineInstrBuilder
based on the instruction type, so we don't have to do that explicitly. However, in
reviewing the debug output, I noticed that the operand was not marked as 'dead'. 
The machine combiner should do that to preserve future optimization opportunities 
that may be checking for that dead EFLAGS operand themselves.

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

llvm-svn: 243990

It's not valid code (maybe it can be made valid, but I'm not sure how).
To trigger the crash fixed in r243987 requires a friend function with
more than four template parameter lists. With this test we have at least
some coverage.

llvm-svn: 243989

llvm-svn: 243988

SmallVector::set_size does not reallocate the vector. Sadly I have no
idea how to test this. The vector never has more than one member in all
of the regression tests.

Found by inspection.

llvm-svn: 243987

Summary:
Previously, we would check whether the target is supported or not, only in
fastSelectInstruction(). This means that 64-bit targets could use FastISel too.
We fix this by checking every overridden method of the FastISel class and
by falling back to SelectionDAG if the target isn't supported. This change
should have been committed along with r243638, but somehow I missed it.

Reviewers: dsanders

Subscribers: llvm-commits

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

llvm-svn: 243986

It was already using just code that is common to all object files.

llvm-svn: 243985

Revert r229675 - [mips] Avoid redundant sign extension of the result of binary bitwise instructions.

It introduced two regressions on 64-bit big-endian targets running under N32
(MultiSource/Benchmarks/tramp3d-v4/tramp3d-v4, and
MultiSource/Applications/kimwitu++/kc) The issue is that on 64-bit targets
comparisons such as BEQ compare the whole GPR64 but incorrectly tell the
instruction selector that they operate on GPR32's. This leads to the
elimination of i32->i64 extensions that are actually required by
comparisons to work correctly.

There's currently a patch under review that fixes this problem.

llvm-svn: 243984

llvm-svn: 243983

llvm-svn: 243982

Even though read-only accesses to scalars outside of a scop do not need to be
modeled to derive valid transformations or to generate valid sequential code,
but information about them is useful when we considering memory footprint
analysis and/or kernel offloading.

llvm-svn: 243981

When we were using a std::sort over all the chunks we needed to put them in a
single storage.

Now that we just iterate over them and use a map to find the output section,
we can avoid allocating the temporary storage.

llvm-svn: 243980

set_size only resets the end pointer and asserts if it is used to grow
the buffer. This would crash when mangling a float with more than 80 bits,
add a test with a ppc double double (128 bits).

Found by inspection.

llvm-svn: 243979

llvm-svn: 243978

llvm-svn: 243977

r243883 and r243961 made a use-after-free far more likely:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/6041/steps/check-llvm%20asan/logs/stdio

Unresolved nodes get inserted into the `Cycles` array.  If they later
get resolved through RAUW, we need to update the reference.  It's
interesting that this never hit before (maybe an asan-ified clang
bootstrap with `-flto -g` would have hit it, but I admit I haven't tried
anything quite that crazy).

llvm-svn: 243976

Summary:
* Remove extraneous members that were just storing temporary
  values.
* OutOfBand_e parameters don't need to be const as they are
  scalars.
* Switch from a map with CMIUtilString values to using a mapping
  function. This uses a switch statement which will generate
  a warning if a new result class is added.
* Make BuildAsyncRecord a static function rather than a private
  member function so that we can construct the result text
  correctly and avoid having extra stuff in the header.

Reviewers: abidh, ki.stfu

Subscribers: lldb-commits

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

llvm-svn: 243975

No functionality change intended.

llvm-svn: 243974

That's just ugly and not needed in this case. No functionality change.

llvm-svn: 243973

This brings ASTContext closer to LLVM's Allocator concept. Ideally we
would just derive ASTContext from llvm::AllocatorBase, but that does
not work because ASTContext's allocator is mutable and we allocate using
const ASTContext& everywhere.

llvm-svn: 243972