llvm-svn: 244011

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

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

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

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: 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

This change was done as an audit and is by inspection.  The new EH
system is still very much a work in progress.  NFC for the landingpad
case.

llvm-svn: 243965

These aren't vector demanded bits tests. More tests to follow.

llvm-svn: 243963

This will make some upcoming bugfixes + improvements easier to manage.

llvm-svn: 243962

r243883 started moving 'distinct' nodes instead of duplicated them in
lib/Linker.  This had the side-effect of sometimes not cloning uniqued
nodes that reference them.  I missed a corner case:

    !named = !{!0}
    !0 = !{!1}
    !1 = distinct !{!0}

!0 is the entry point for "remapping", and a temporary clone (say,
!0-temp) is created and mapped in case we need to model a uniquing
cycle.

    Recursive descent into !1.  !1 is distinct, so we leave it alone,
    but update its operand to !0-temp.

Pop back out to !0.  Its only operand, !1, hasn't changed, so we don't
need to use !0-temp.  !0-temp goes out of scope, and we're finished
remapping, but we're left with:

    !named = !{!0}
    !0 = !{!1}
    !1 = distinct !{null} ; uh oh...

Previously, if !0 and !0-temp ended up with identical operands, then
!0-temp couldn't have been referenced at all.  Now that distinct nodes
don't get duplicated, that assumption is invalid.  We need to
!0-temp->replaceAllUsesWith(!0) before freeing !0-temp.

I found this while running an internal `-flto -g` bootstrap.  Strangely,
there was no case of this in the open source bootstrap I'd done before
commit...

llvm-svn: 243961

Requires "native" feature in most places that were failing.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 243960

These tests rely on the native backend to be built-in.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 243959

The goal is to have 'ninja check' passing even if the X86 backend is
not built.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 243958

If we don't have sys/wait.h and we're on a unix system there's no way
that several of the llvm tools work at all. This includes clang.

Just remove the configure and cmake checks entirely - we'll get a
build error instead of building something broken now.

llvm-svn: 243957

On the code path in ExpandUnalignedLoad which expands an unaligned vector/fp
value in terms of a legal integer load of the same size, the ChainResult needs
to be the chain result of the integer load.

No in-tree test case is currently available.

Patch by Jan Hranac!

llvm-svn: 243956

This variant of addRuntimeCheck is only used now from the LoopVectorizer
which does not use this parameter.

llvm-svn: 243955

Summary: This patch adds enum value for an existing metadata type -- make.implicit. Using preassigned enum will be helpful to get compile time type checking and avoid string construction and comparison. The patch also changes uses of make.implicit from string metadata to enum metadata. There is no functionality change.

Reviewers: reames

Subscribers: llvm-commits

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

llvm-svn: 243954

This adds the software division routines for the Windows RTABI.  These are not
expected to be used often though as most modern Windows ARM capable targets
support hardware division.  In the case that the target CPU doesnt support
hardware division, this will be the fallback.

llvm-svn: 243952

Make the libcall updating table driven similar to the approach that the Linux
and Windows codepath does below.  NFC.

llvm-svn: 243951

contained types into the space when we have no contained types. This
fixes the UB stemming from a call to memcpy with a null pointer. This
also reduces the calls to allocate because this actually happens in
a notable client - Clang.

Found by UBSan.

llvm-svn: 243944

Looks like the rebased version that Mehdi committed didn't incorporate
the latest changes.

Patch by Erik de Castro Lopo <erikd@mega-nerd.com>!

llvm-svn: 243942

This reverts commit r243348 and r243357.  They caused PR24347.

llvm-svn: 243939

Some are named "FP", others "SD", others still "FP*SD".
Rename all this to just use "FP", which, except for conversions
(which don't use this format naming scheme), implies "SD" anyway.

llvm-svn: 243936

llvm-svn: 243935

this is the last of them in my build of LLVM. Haven't tried Clang yet.

Found via UBSan.

llvm-svn: 243934

It's already in SysRegMappings, no need to also have it in MSRMappings:
the latter is only used if we didn't find a match in the former.

llvm-svn: 243933

This too was found by UBSan. Down to 35 failures for me.

llvm-svn: 243932

llvm-svn: 243931

llvm-svn: 243930

llvm-svn: 243929

This happens to work, but is not guaranteed to work. Indeed, most memcpy
interfaces in Linux-land annotate these arguments as nonnull, and GCC
and LLVM both can and do optimized based upon that. When they do so,
they might legitimately have miscompiled code calling this routine with
two valid iterators, 'nullptr' and 'nullptr'. There was even code doing
precisely this because StringRef().begin() and StringRef().end() both
produce null pointers.

This was found by UBSan.

llvm-svn: 243927

There's a bunch of code in LowerFCOPYSIGN that does smart lowering, and
is actually already vector-aware; let's use it instead of scalarizing!

The only interesting change is that for v2f32, we previously always used
use v4i32 as the integer vector type.
Use v2i32 instead, and mark FCOPYSIGN as Custom.

llvm-svn: 243926

We used to legalize it like it's any other binary operations.  It's not,
because it accepts mismatched operand types.  Because of that, we used
to hit various asserts and miscompiles.

Specialize vector legalizations to, in the worst case, unroll, or, when
possible, to just legalize the operand that needs legalization.

Scalarization isn't covered, because I can't think of a target where
some but not all of the 1-element vector types are to be scalarized.

llvm-svn: 243924

llvm-svn: 243923

llvm-svn: 243921