- Jul 02, 2013
-
-
David Blaikie authored
llvm-svn: 185398
-
Michael Gottesman authored
rdar://14323230 llvm-svn: 185397
-
Richard Trieu authored
for assert(0 && "text"). llvm-svn: 185396
-
Jakob Stoklund Olesen authored
llvm-svn: 185395
-
Ulrich Weigand authored
[PowerPC] Add support for TLS data relocations This adds support for TLS data relocations and modifiers: .quad target@dtpmod .quad target@tprel .quad target@dtprel Currently exploited by the asm parser only. llvm-svn: 185394
-
Jakob Stoklund Olesen authored
Patch by Benjamin Kramer! Use the BlockFrequency class instead of floats in the Hopfield network computations. This rescales the node Bias field from a [-2;2] float range to two block frequencies BiasN and BiasP pulling in opposite directions. This construct has a more predictable behavior when block frequencies saturate. The per-node scaling factors are no longer necessary, assuming the block frequencies around a bundle are consistent. This patch can cause the register allocator to make different spilling decisions. The differences should be small. llvm-svn: 185393
-
Richard Trieu authored
llvm-svn: 185392
-
Howard Hinnant authored
llvm-svn: 185391
-
Ulrich Weigand authored
[PowerPC] Fix 32-bit PowerPC TLS relocs Some TLS relocs were copied incorrectly from ppc64 to ppc32, and some were missing completely. llvm-svn: 185390
-
- Jul 01, 2013
-
-
David Blaikie authored
Restrict the current TLS support to X86 ELF for now. Test that we don't produce it on PPC & we can flesh that test case out with the right thing once someone implements it. llvm-svn: 185389
-
Greg Clayton authored
llvm-svn: 185388
-
Ulrich Weigand authored
[PowerPC] Support all condition register logical instructions This adds support for all missing condition register logical instructions and extended mnemonics to the asm parser. llvm-svn: 185387
-
Greg Clayton authored
llvm-svn: 185386
-
Chad Rosier authored
llvm-svn: 185385
-
Eli Friedman authored
llvm-svn: 185384
-
Manman Ren authored
No functionality change. It should suffice to check the type of a debug info metadata, instead of calling Verify. llvm-svn: 185383
-
Greg Clayton authored
Recognize "decltype(nullptr)" as a valid DW_AT_name for DW_TAG_unspecified_type tags as meaning the C++11 null pointer type. llvm-svn: 185382
-
Eli Friedman authored
The key insight here is that weak linkage for a static local variable should always mean linkonce_odr, because every file that needs it will generate a definition. We don't actually care about the precise linkage of the parent context. I feel a bit silly that I didn't realize this before. llvm-svn: 185381
-
Bill Schmidt authored
=================================================================== --- test/CodeGen/PowerPC/reloc-align.ll (revision 0) +++ test/CodeGen/PowerPC/reloc-align.ll (revision 0) @@ -0,0 +1,34 @@ +; RUN: llc -mcpu=pwr7 -O1 < %s | FileCheck %s + +; This test verifies that the peephole optimization of address accesses +; does not produce a load or store with a relocation that can't be +; satisfied for a given instruction encoding. Reduced from a test supplied +; by Hal Finkel. + +target datalayout = "E-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-f128:128:128-v128:128:128-n32:64" +target triple = "powerpc64-unknown-linux-gnu" + +%struct.S1 = type { [8 x i8] } + +@main.l_1554 = internal global { i8, i8, i8, i8, i8, i8, i8, i8 } { i8 -1, i8 -6, i8 57, i8 62, i8 -48, i8 0, i8 58, i8 80 }, align 1 + +; Function Attrs: nounwind readonly +define signext i32 @main() #0 { +entry: + %call = tail call fastcc signext i32 @func_90(%struct.S1* byval bitcast ({ i8, i8, i8, i8, i8, i8, i8, i8 }* @main.l_1554 to %struct.S1*)) +; CHECK-NOT: ld {{[0-9]+}}, main.l_1554@toc@l + ret i32 %call +} + +; Function Attrs: nounwind readonly +define internal fastcc signext i32 @func_90(%struct.S1* byval nocapture %p_91) #0 { +entry: + %0 = bitcast %struct.S1* %p_91 to i64* + %bf.load = load i64* %0, align 1 + %bf.shl = shl i64 %bf.load, 26 + %bf.ashr = ashr i64 %bf.shl, 54 + %bf.cast = trunc i64 %bf.ashr to i32 + ret i32 %bf.cast +} + +attributes #0 = { nounwind readonly "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf"="true" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "unsafe-fp-math"="false" "use-soft-float"="false" } Index: lib/Target/PowerPC/PPCAsmPrinter.cpp =================================================================== --- lib/Target/PowerPC/PPCAsmPrinter.cpp (revision 185327) +++ lib/Target/PowerPC/PPCAsmPrinter.cpp (working copy) @@ -679,7 +679,26 @@ void PPCAsmPrinter::EmitInstruction(const MachineI OutStreamer.EmitRawText(StringRef("\tmsync")); return; } + break; + case PPC::LD: + case PPC::STD: + case PPC::LWA: { + // Verify alignment is legal, so we don't create relocations + // that can't be supported. + // FIXME: This test is currently disabled for Darwin. The test + // suite shows a handful of test cases that fail this check for + // Darwin. Those need to be investigated before this sanity test + // can be enabled for those subtargets. + if (!Subtarget.isDarwin()) { + unsigned OpNum = (MI->getOpcode() == PPC::STD) ? 2 : 1; + const MachineOperand &MO = MI->getOperand(OpNum); + if (MO.isGlobal() && MO.getGlobal()->getAlignment() < 4) + llvm_unreachable("Global must be word-aligned for LD, STD, LWA!"); + } + // Now process the instruction normally. + break; } + } LowerPPCMachineInstrToMCInst(MI, TmpInst, *this); OutStreamer.EmitInstruction(TmpInst); Index: lib/Target/PowerPC/PPCISelDAGToDAG.cpp =================================================================== --- lib/Target/PowerPC/PPCISelDAGToDAG.cpp (revision 185327) +++ lib/Target/PowerPC/PPCISelDAGToDAG.cpp (working copy) @@ -1530,6 +1530,14 @@ void PPCDAGToDAGISel::PostprocessISelDAG() { if (GlobalAddressSDNode *GA = dyn_cast<GlobalAddressSDNode>(ImmOpnd)) { SDLoc dl(GA); const GlobalValue *GV = GA->getGlobal(); + // We can't perform this optimization for data whose alignment + // is insufficient for the instruction encoding. + if (GV->getAlignment() < 4 && + (StorageOpcode == PPC::LD || StorageOpcode == PPC::STD || + StorageOpcode == PPC::LWA)) { + DEBUG(dbgs() << "Rejected this candidate for alignment.\n\n"); + continue; + } ImmOpnd = CurDAG->getTargetGlobalAddress(GV, dl, MVT::i64, 0, Flags); } else if (ConstantPoolSDNode *CP = dyn_cast<ConstantPoolSDNode>(ImmOpnd)) { llvm-svn: 185380
-
Chad Rosier authored
tablegen enum values. This should be the last fix due to fallout from r185094. llvm-svn: 185379
-
Lang Hames authored
llvm-svn: 185378
-
Sean Silva authored
"Writing an LLVM Compiler Backend" can be misinterpreted as meaning "backend" in the sense of "using LLVM as a backend for your compiler for your new language". This new name is less ambiguous. As a bonus, this brings the title in line with the file name. llvm-svn: 185377
-
Akira Hatanaka authored
have three register operands. No intended functionality changes. llvm-svn: 185376
-
Ulrich Weigand authored
[PowerPC] Also add "msync" alias This adds an alias for "msync" (which is used on Book E systems instead of "sync"). llvm-svn: 185375
-
Eli Friedman authored
Sorry about that. llvm-svn: 185374
-
Akira Hatanaka authored
Create a dedicated register class for floating point condition code registers and move FCC0 from register class CCR to the new register class. llvm-svn: 185373
-
Eli Friedman authored
Blocks, like lambdas, can be written in contexts which are required to be treated as the same under ODR. Unlike lambdas, it isn't possible to actually take the address of a block, so the mangling of the block itself doesn't matter. However, objects like static variables inside a block do need to be mangled in a consistent way. There are basically three components here. One, block literals need a consistent numbering. Two, objects/types inside a block literal need to be mangled using it. Three, objects/types inside a block literal need to have their linkage computed correctly. llvm-svn: 185372
-
Akira Hatanaka authored
llvm-svn: 185371
-
Anton Korobeynikov authored
llvm-svn: 185369
-
Anton Korobeynikov authored
llvm-svn: 185368
-
Cameron Zwarich authored
llvm-svn: 185367
-
Michael Sartain authored
llvm-svn: 185366
-
Anton Korobeynikov authored
Patch by Job Noorman! llvm-svn: 185364
-
Cameron Zwarich authored
When phis get lowered, destination copies are inserted using an iterator that is determined once for all phis in the block, which BuildMI interprets as a request to insert an instruction directly before the iterator. In the case of a cyclic phi, source copies may also be inserted directly before this iterator, which can cause source copies to be inserted before destination copies. The fix is to keep an iterator to the last phi and then advance it while lowering each phi in order to insert destination copies directly after the phis. llvm-svn: 185363
-
Anton Korobeynikov authored
Patch by Job Noorman! llvm-svn: 185362
-
Hal Finkel authored
Although you can't generate this from C on PPC64, if you have a loop using a 64-bit counter on PPC32 then you can't form a CTR-based loop for it. This had been cauing the PPCCTRLoops pass to assert. Thanks to Joerg Sonnenberger for providing a test case! llvm-svn: 185361
-
Tim Northover authored
According to the AArch64 ELF specification (4.6.8), it's the assembler's responsibility to make sure the shift amount is correct in relocated MOVZ/MOVK instructions. This wasn't being obeyed by either the MCJIT CodeGen or RuntimeDyldELF (which happened to work out well for JIT tests). This commit should make us compliant in this area. llvm-svn: 185360
-
Matt Beaumont-Gay authored
(2) Rename llvm-cov test inputs so the string "llvm-cov" doesn't get substituted by lit within the input filenames on the RUN line. (3) XFAIL llvm-cov.test because it asserts: include/llvm/ADT/SmallVector.h:140: reference llvm::SmallVectorTemplateCommon<llvm::GCOVBlock *, void>::operator[](unsigned int) [T = llvm::GCOVBlock *]: Assertion `begin() + idx < end()' failed. llvm-svn: 185358
-
Jim Ingham authored
llvm-svn: 185357
-
Tim Northover authored
Turns out I'd misread the architecture reference manual and thought that was a load/store-store barrier, when it's not. Thanks for pointing it out Eli! llvm-svn: 185356
-