sys::IdentifyFileType is already conscious of the length, and
object_error::invalid_file_type is returned below anyway if
sys::IdentifyFileType doesn't recognize the file.

llvm-svn: 183605

llvm-svn: 183601

destination operands of an instruction.

No functionality changes.

llvm-svn: 183596

instantiation issue with non-standard type.

Add a backend option to warn on a given stack size limit.
Option: -mllvm -warn-stack-size=<limit>
Output (if limit is exceeded):
warning: Stack size limit exceeded (<actual size>) in <functionName>.

The longer term plan is to hook that to a clang warning.
PR:4072
<rdar://problem/13987214>.

llvm-svn: 183595

This is using a hint from AMD APP OpenCL Programming Guide with
empirically tweaked parameters.
I used Unigine Heaven 3.0 to determine best parameters on my system
(i7 2600/Radeon 6950/Kernel 3.9.4) the benchmark :
it went from 38.8 average fps to 39.6, which is ~3% gain.
(Lightmark 2008.2 gain is much more marginal: from 537 to 539)

There is no lit test provided as the parameter were determined
empirically and it it would be nearly impossiblet to find a test
program that check for optimal behavior.

llvm-svn: 183593

llvm-svn: 183592

llvm-svn: 183589

llvm-svn: 183587

  The MemCpyOpt pass is capable of optimizing:
      callee(&S); copy N bytes from S to D.
    into:
      callee(&D);
subject to some legality constraints. 

  Assertion is triggered when the compiler tries to evalute "sizeof(typeof(D))",
while D is an opaque-typed, 'sret' formal argument of function being compiled.
i.e. the signature of the func being compiled is something like this:
  T caller(...,%opaque* noalias nocapture sret %D, ...)

  The fix is that when come across such situation, instead of calling some
utility functions to get the size of D's type (which will crash), we simply
assume D has at least N bytes as implified by the copy-instruction.

rdar://14073661 

llvm-svn: 183584

On PPC32, [su]div,rem on i64 types are transformed into runtime library
function calls. As a result, they are not allowed in counter-based loops (the
counter-loops verification pass caught this error; this change fixes PR16169).

llvm-svn: 183581

llvm-svn: 183579

the internals of TargetMachine could change.

No functionality change intended.

llvm-svn: 183572

the internals of TargetMachine could change.

No functionality change intended.

llvm-svn: 183571

llvm-svn: 183570

We weren't computing structure size correctly and we were relying on
the original alloca instruction to compute the offset, which isn't
always reliable.

Reviewed-by: Vincent Lejeune <vljn@ovi.com>
llvm-svn: 183568

the internals of TargetMachine could change.

No functionality change intended.

llvm-svn: 183567

This should simplify the subtarget definitions and make it easier to
add new ones.

Reviewed-by: Vincent Lejeune <vljn@ovi.com>
llvm-svn: 183566

the internals of TargetMachine could change.

No functionality change intended.

llvm-svn: 183565

the internals of TargetMachine could change.

No functionality change intended.

llvm-svn: 183561

Reviewed-by: Vincent Lejeune <vljn@ovi.com>

https://bugs.freedesktop.org/show_bug.cgi?id=64257

llvm-svn: 183560

This is the convention used by the other targets.

Reviewed-by: Vincent Lejeune <vljn@ovi.com>
llvm-svn: 183559

Reviewed-by: Vincent Lejeune <vljn@ovi.com>
llvm-svn: 183558

Option: -mllvm -warn-stack-size=<limit>
Output (if limit is exceeded):
warning: Stack size limit exceeded (<actual size>) in <functionName>.

The longer term plan is to hook that to a clang warning.
PR:4072
<rdar://problem/13987214>

llvm-svn: 183552

My recent ARM FastISel patch exposed this bug:
  http://llvm.org/bugs/show_bug.cgi?id=16178
The root cause is that it can't select integer sext/zext pre-ARMv6 and
asserts out.

The current integer sext/zext code doesn't handle other cases gracefully
either, so this patch makes it handle all sext and zext from i1/i8/i16
to i8/i16/i32, with and without ARMv6, both in Thumb and ARM mode. This
should fix the bug as well as make FastISel faster because it bails to
SelectionDAG less often. See fastisel-ext.patch for this.

fastisel-ext-tests.patch changes current tests to always use reg-imm AND
for 8-bit zext instead of UXTB. This simplifies code since it is
supported on ARMv4t and later, and at least on A15 both should perform
exactly the same (both have exec 1 uop 1, type I).

2013-05-31-char-shift-crash.ll is a bitcode version of the above bug
16178 repro.

fast-isel-ext.ll tests all sext/zext combinations that ARM FastISel
should now handle.

Note that my ARM FastISel enabling patch was reverted due to a separate
failure when dealing with MCJIT, I'll fix this second failure and then
turn FastISel on again for non-iOS ARM targets.

I've tested "make check-all" on my x86 box, and "lnt test-suite" on A15
hardware.

llvm-svn: 183551

Found be libstdc's debug mode.

llvm-svn: 183549

Fix an assertion when the compiler encounters big constants whose bit width is
not a multiple of 64-bits.
Although clang would never generate something like this, the backend should be
able to handle any legal IR.

<rdar://problem/13363576>

llvm-svn: 183544

Use the correct DIType when creating types in DIBuilder.

llvm-svn: 183543

llvm-svn: 183541

Thanks to Benjamin Kramer for the suggestion.

llvm-svn: 183540

I am able to compile/assemble/link/run /bin/echo from FreeBSD.

llvm-svn: 183537

OpenBSD's stack smashing protection differs slightly from other
platforms:

  1. The smash handler function is "__stack_smash_handler(const char
     *funcname)" instead of "__stack_chk_fail(void)".

  2. There's a hidden "long __guard_local" object that gets linked
     into each executable and DSO.

Patch by Matthew Dempsky.

llvm-svn: 183533

As a bonus this reduces the loop from O(n^2) to O(n).

llvm-svn: 183532

llvm-svn: 183528

Avoids unused variable warnings in Release builds.

llvm-svn: 183512

llvm-svn: 183495

the internals of TargetMachine could change.

No functionality change intended.

llvm-svn: 183494

the internals of TargetMachine could change.

llvm-svn: 183493

the internals of TargetMachine could change.

llvm-svn: 183492

the internals of TargetMachine could change.

llvm-svn: 183491

the internals of TargetMachine could change.

llvm-svn: 183490