summaryrefslogtreecommitdiffstats
path: root/llvm/test
Commit message (Collapse)AuthorAgeFilesLines
* [Hexagon] Adding accumulating add/sub, doubleword logic-not variants, ↵Colin LeMahieu2014-12-313-0/+24
| | | | | | doubleword bitfield extract, word parity, accumulating multiplies with saturation. llvm-svn: 225024
* Fix a test case to not depend on asm comment syntax, so as to be portableDavid Blaikie2014-12-301-9/+9
| | | | | | | | 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
* Generalize even further, for ARM comment syntax (@)David Blaikie2014-12-301-8/+8
| | | | llvm-svn: 225019
* [Hexagon] Adding double-logic on predicate instructions.Colin LeMahieu2014-12-301-2/+22
| | | | llvm-svn: 225018
* Generalize test case to handle different asm syntax (# or // comments)David Blaikie2014-12-301-8/+8
| | | | llvm-svn: 225017
* [Hexagon] Adding newvalue compare and jumps.Colin LeMahieu2014-12-301-0/+134
| | | | llvm-svn: 225015
* DebugInfo: Omit is_stmt from line table entries on the same line.David Blaikie2014-12-302-1/+82
| | | | | | | | | | | | | | | | | | | | | | 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
* [Hexagon] Adding postincrement register newvalue stores.Colin LeMahieu2014-12-301-0/+9
| | | | llvm-svn: 225010
* [Hexagon] Removing old newvalue store variants. Adding postincrement ↵Colin LeMahieu2014-12-301-0/+51
| | | | | | immediate newvalue stores. llvm-svn: 225009
* [mips][microMIPS] Relocate with symbol for micromips symbolsZoran Jovanovic2014-12-301-0/+16
| | | | | | Differential Revision: http://reviews.llvm.org/D6796 llvm-svn: 225008
* [Hexagon] Adding indexed store new-value variants.Colin LeMahieu2014-12-301-0/+51
| | | | llvm-svn: 225007
* [Hexagon] Adding indexed store of immediates.Colin LeMahieu2014-12-301-0/+36
| | | | llvm-svn: 225006
* [Hexagon] Adding indexed stores.Colin LeMahieu2014-12-302-0/+115
| | | | llvm-svn: 225005
* x86_64: Fix calls to __morestack under the large code model.Peter Collingbourne2014-12-301-0/+15
| | | | | | | | | | | | | | | | | | | | 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] change _sanitizer_cov_module_init to accept int* instead of int**Kostya Serebryany2014-12-301-1/+1
| | | | llvm-svn: 224999
* [COFF] Don't try to add quotes to already quoted linker directivesMichael Kuperstein2014-12-301-1/+2
| | | | | | | | | | 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
* [Hexagon] Adding reg-reg indexed load forms.Colin LeMahieu2014-12-303-9/+81
| | | | llvm-svn: 224997
* [Hexagon] Adding compare byte/halfword reg-reg/reg-imm forms. Adding ↵Colin LeMahieu2014-12-302-0/+28
| | | | | | compare to general register reg-imm form. llvm-svn: 224991
* [Hexagon] Updating constant extender def, adding alu-not instructions, ↵Colin LeMahieu2014-12-302-4/+17
| | | | | | compare to general register, and inverted compares. llvm-svn: 224989
* Remove doesSectionRequireSymbols.Rafael Espindola2014-12-303-0/+124
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Simplify test a bit.Rafael Espindola2014-12-301-516/+3
| | | | | | | | | | It looks like the original intent was to check which symbols were created. With macho-dump the sections were being checked just to match which symbol was in which section. llvm-objdump prints the section a symbol is in. llvm-svn: 224980
* [OCaml] Fix bitrot in tests.Peter Zotov2014-12-301-2/+2
| | | | llvm-svn: 224979
* [lit] Make config.llvm_lib_dir available on cmake, too.Peter Zotov2014-12-302-2/+2
| | | | | | | The OCaml tests require config.llvm_lib_dir to determine the OCaml package search path. llvm-svn: 224978
* Testcases for r224939.Craig Topper2014-12-301-0/+17
| | | | llvm-svn: 224976
* Convert test to llvm-readobj. NFC.Rafael Espindola2014-12-301-127/+214
| | | | llvm-svn: 224973
* Semantic tests for memory invalidation at statepointsPhilip Reames2014-12-291-0/+108
| | | | | | | | | | These are simply a collection of tests intended to show that information about the contents of gc references in the heap is lost at a statepoint. I've tried to write them so that they don't disallow correct transformations, while still being fairly easy to understand. p.s. Ideas for additional tests are welcome. Differential Revision: http://reviews.llvm.org/D6491 llvm-svn: 224971
* Carry facts about nullness and undef across GC relocationPhilip Reames2014-12-291-0/+52
| | | | | | | | | | | | | | | This change implements four basic optimizations: If a relocated value isn't used, it doesn't need to be relocated. If the value being relocated is null, relocation doesn't change that. (Technically, this might be collector specific. I don't know of one which it doesn't work for though.) If the value being relocated is undef, the relocation is meaningless. If the value being relocated was known nonnull, the relocated pointer also isn't null. (Since it points to the same source language object.) I outlined other planned work in comments. Differential Revision: http://reviews.llvm.org/D6600 llvm-svn: 224968
* Refine the notion of MayThrow in LICM to include a header specific versionPhilip Reames2014-12-291-0/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In LICM, we have a check for an instruction which is guaranteed to execute and thus can't introduce any new faults if moved to the preheader. To handle a function which might unconditionally throw when first called, we check for any potentially throwing call in the loop and give up. This is unfortunate when the potentially throwing condition is down a rare path. It prevents essentially all LICM of potentially faulting instructions where the faulting condition is checked outside the loop. It also greatly diminishes the utility of loop unswitching since control dependent instructions - which are now likely in the loops header block - will not be lifted by subsequent LICM runs. define void @nothrow_header(i64 %x, i64 %y, i1 %cond) { ; CHECK-LABEL: nothrow_header ; CHECK-LABEL: entry ; CHECK: %div = udiv i64 %x, %y ; CHECK-LABEL: loop ; CHECK: call void @use(i64 %div) entry: br label %loop loop: ; preds = %entry, %for.inc %div = udiv i64 %x, %y br i1 %cond, label %loop-if, label %exit loop-if: call void @use(i64 %div) br label %loop exit: ret void } The current patch really only helps with non-memory instructions (i.e. divs, etc..) since the maythrow call down the rare path will be considered to alias an otherwise hoistable load. The one exception is that it does kick in for loads which are known to be invariant without regard to other possible stores, i.e. those marked with either !invarant.load metadata of tbaa 'is constant memory' metadata. Differential Revision: http://reviews.llvm.org/D6725 llvm-svn: 224965
* Loading from null is valid outside of addrspace 0Philip Reames2014-12-291-0/+20
| | | | | | | | | | This patches fixes a miscompile where we were assuming that loading from null is undefined and thus we could assume it doesn't happen. This transform is perfectly legal in address space 0, but is not neccessarily legal in other address spaces. We really should introduce a hook to control this property on a per target per address space basis. We may be loosing valuable optimizations in some address spaces by being too conservative. Original patch by Thomas P Raoux (submitted to llvm-commits), tests and formatting fixes by me. llvm-svn: 224961
* Convert test to llvm-readobj. NFC.Rafael Espindola2014-12-291-16/+41
| | | | llvm-svn: 224959
* [Hexagon] Adding allocframe, post-increment circular immediate stores, ↵Colin LeMahieu2014-12-291-1/+34
| | | | | | post-increment circular register stores, and bit reversed post-increment stores. llvm-svn: 224957
* [Hexagon] Adding post-increment register form stores and register-immediate ↵Colin LeMahieu2014-12-293-2/+84
| | | | | | form stores with tests. llvm-svn: 224952
* [Hexagon] Replacing the remaining postincrement stores with versions that ↵Colin LeMahieu2014-12-291-1/+40
| | | | | | have encoding bits. llvm-svn: 224951
* Convert test to FileCheck. NFC.Rafael Espindola2014-12-291-876/+877
| | | | llvm-svn: 224950
* [Hexagon] Renaming old multiclass for removal. Adding post-increment store ↵Colin LeMahieu2014-12-291-0/+14
| | | | | | classes and instruction defs. llvm-svn: 224949
* Add segmented stack support for DragonFlyBSD.Rafael Espindola2014-12-291-0/+108
| | | | | | Patch by Michael Neumann. llvm-svn: 224936
* llvm/test/CodeGen/X86/fast-isel-call-bool.ll: Add explicit ↵NAKAMURA Takumi2014-12-281-1/+1
| | | | | | -mtriple=x86_64-unknown to satisfy x64. llvm-svn: 224907
* [X86][ISel] Fix a regression I introduced in r224884Keno Fischer2014-12-282-2/+14
| | | | | | | | | | | | | The else case ResultReg was not checked for validity. To my surprise, this case was not hit in any of the existing test cases. This includes a new test cases that tests this path. Also drop the `target triple` declaration from the original test as suggested by H.J. Lu, because apparently with it the test won't be run on Linux llvm-svn: 224901
* [X86] Add missing memory variants to AVX false dependency breakingMichael Kuperstein2014-12-282-62/+73
| | | | | | | | Adds missing memory instruction variants to AVX false dependency breaking handling. (SSE was handled in r224246) Differential Revision: http://reviews.llvm.org/D6780 llvm-svn: 224900
* [CodeGenPrepare] Teach when it is profitable to speculate calls to ↵Andrea Di Biagio2014-12-281-0/+250
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | @llvm.cttz/ctlz. If the control flow is modelling an if-statement where the only instruction in the 'then' basic block (excluding the terminator) is a call to cttz/ctlz, CodeGenPrepare can try to speculate the cttz/ctlz call and simplify the control flow graph. Example: \code entry: %cmp = icmp eq i64 %val, 0 br i1 %cmp, label %end.bb, label %then.bb then.bb: %c = tail call i64 @llvm.cttz.i64(i64 %val, i1 true) br label %end.bb end.bb: %cond = phi i64 [ %c, %then.bb ], [ 64, %entry] \code In this example, basic block %then.bb is taken if value %val is not zero. Also, the phi node in %end.bb would propagate the size-of in bits of %val only if %val is equal to zero. With this patch, CodeGenPrepare will try to hoist the call to cttz from %then.bb into basic block %entry only if cttz is cheap to speculate for the target. Added two new hooks in TargetLowering.h to let targets customize the behavior (i.e. decide whether it is cheap or not to speculate calls to cttz/ctlz). The two new methods are 'isCheapToSpeculateCtlz' and 'isCheapToSpeculateCttz'. By default, both methods return 'false'. On X86, method 'isCheapToSpeculateCtlz' returns true only if the target has LZCNT. Method 'isCheapToSpeculateCttz' only returns true if the target has BMI. Differential Revision: http://reviews.llvm.org/D6728 llvm-svn: 224899
* Scalarizer for masked load and store intrinsics.Elena Demikhovsky2014-12-281-0/+15
| | | | | | | | Masked vector intrinsics are a part of common LLVM IR, but they are really supported on AVX2 and AVX-512 targets. I added a code that translates masked intrinsic for all other targets. The masked vector intrinsic is converted to a chain of scalar operations inside conditional basic blocks. http://reviews.llvm.org/D6436 llvm-svn: 224897
* PowerPC: CTR shouldn't fire if a TLS call is in the loopDavid Majnemer2014-12-271-1/+24
| | | | | | | | | | | | | | | Determining the address of a TLS variable results in a function call in certain TLS models. This means that a simple ICmpInst might actually result in invalidating the CTR register. In such cases, do not attempt to rely on the CTR register for loop optimization purposes. This fixes PR22034. Differential Revision: http://reviews.llvm.org/D6786 llvm-svn: 224890
* [FastIsel][X86] Fix invalid register replacement for bool argsKeno Fischer2014-12-271-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Consider the following IR: %3 = load i8* undef %4 = trunc i8 %3 to i1 %5 = call %jl_value_t.0* @foo(..., i1 %4, ...) ret %jl_value_t.0* %5 Bools (that are the result of direct truncs) are lowered as whatever the argument to the trunc was and a "and 1", causing the part of the MBB responsible for this argument to look something like this: %vreg8<def,tied1> = AND8ri %vreg7<kill,tied0>, 1, %EFLAGS<imp-def>; GR8:%vreg8,%vreg7 Later, when the load is lowered, it will insert %vreg15<def> = MOV8rm %vreg14, 1, %noreg, 0, %noreg; mem:LD1[undef] GR8:%vreg15 GR64:%vreg14 but remember to (at the end of isel) replace vreg7 by vreg15. Now for the bug. In fast isel lowering, we mistakenly mark vreg8 as the result of the load instead of the trunc. This adds a fixup to have vreg8 replaced by whatever the result of the load is as well, so we end up with %vreg15<def,tied1> = AND8ri %vreg15<kill,tied0>, 1, %EFLAGS<imp-def>; GR8:%vreg15 which is an SSA violation and causes problems later down the road. This fixes PR21557. Test Plan: Test test case from PR21557 is added to the test suite. Reviewers: ributzka Reviewed By: ributzka Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6245 llvm-svn: 224884
* Convert test to llvm-readobj. NFC.Rafael Espindola2014-12-261-318/+361
| | | | llvm-svn: 224872
* [Hexagon] Adding auto-incrementing loads with and without byte reversal.Colin LeMahieu2014-12-261-0/+24
| | | | llvm-svn: 224871
* [Hexagon] Adding locked loads.Colin LeMahieu2014-12-261-0/+4
| | | | llvm-svn: 224870
* [Hexagon] Adding deallocframe and circular addressing loads.Colin LeMahieu2014-12-261-0/+39
| | | | llvm-svn: 224869
* [Hexagon] Adding remaining post-increment instruction variants. Removing ↵Colin LeMahieu2014-12-261-0/+36
| | | | | | unused classes. llvm-svn: 224868
* [Hexagon] Adding post-increment unsigned byte loads.Colin LeMahieu2014-12-261-10/+22
| | | | llvm-svn: 224867
* [Hexagon] Adding post-increment signed byte loads with tests.Colin LeMahieu2014-12-261-0/+17
| | | | llvm-svn: 224866
OpenPOWER on IntegriCloud