Test Polly

make polly-test

make polly-test -C tools/polly/test/

Modified: polly/trunk/test/CMakeLists.txt polly/trunk/test/Makefile polly/trunk/test/lit.site.cfg.in Modified: polly/trunk/test/CMakeLists.txt URL: http://llvm.org/viewvc/llvm-project/polly/trunk/test/CMakeLists.txt?rev=145076&r1=145075&r2=145076&view=diff ============================================================================== --- polly/trunk/test/CMakeLists.txt (original) +++ polly/trunk/test/CMakeLists.txt Tue Nov 22 13:40:38 2011 @@ -10,6 +10,7 @@ set(POLLY_SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/..") set(POLLY_BINARY_DIR "${CMAKE_CURRENT_BINARY_DIR}/..") +set(LLVM_SHLIBEXT "${CMAKE_SHARED_LIBRARY_SUFFIX}") if (NOT DEFINED LLVM_MAIN_SRC_DIR) # We are building polly out of tree, adjust the settings. Modified: polly/trunk/test/Makefile URL: http://llvm.org/viewvc/llvm-project/polly/trunk/test/Makefile?rev=145076&r1=145075&r2=145076&view=diff ============================================================================== --- polly/trunk/test/Makefile (original) +++ polly/trunk/test/Makefile Tue Nov 22 13:40:38 2011 @@ -47,6 +47,7 @@ -e "s#@POLLY_SOURCE_DIR@#$(PROJ_SRC_DIR)/..#g" \ -e "s#@POLLY_BINARY_DIR@#$(PROJ_OBJ_DIR)/..#g" \ -e "s#@TARGET_TRIPLE@#$(TARGET_TRIPLE)#g" \ + -e "s#@LLVM_SHLIBEXT@#$(SHLIBEXT)#g" \ $(PROJ_SRC_DIR)/lit.site.cfg.in > $@ clean:: Modified: polly/trunk/test/lit.site.cfg.in URL: http://llvm.org/viewvc/llvm-project/polly/trunk/test/lit.site.cfg.in?rev=145076&r1=145075&r2=145076&view=diff ============================================================================== --- polly/trunk/test/lit.site.cfg.in (original) +++ polly/trunk/test/lit.site.cfg.in Tue Nov 22 13:40:38 2011 @@ -18,7 +18,7 @@ lit.fatal("unable to find %r parameter, use '--param=%s=VALUE'" % (key,key)) config.substitutions.append(('%loadPolly', '-load ' - + config.llvm_libs_dir + '/LLVMPolly.so ')) + + config.llvm_libs_dir + '/LLVMPolly at LLVM_SHLIBEXT@')) config.substitutions.append(('%defaultOpts', ' -basicaa -polly-prepare -polly-region-simplify -scev-aa ')) config.substitutions.append(('%polybenchOpts', ' -O3 -loop-simplify -indvars ')) From adasgupt at codeaurora.org Tue Nov 22 14:03:30 2011 From: adasgupt at codeaurora.org (Anshuman Dasgupta) Date: Tue, 22 Nov 2011 20:03:30 -0000 Subject: [llvm-commits] [llvm] r145078 - /llvm/trunk/README.txt Message-ID: <20111122200330.4AB5D2A6C134@llvm.org> Author: adasgupt Date: Tue Nov 22 14:03:30 2011 New Revision: 145078 URL: http://llvm.org/viewvc/llvm-project?rev=145078&view=rev Log: Test commit Modified: llvm/trunk/README.txt Modified: llvm/trunk/README.txt URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/README.txt?rev=145078&r1=145077&r2=145078&view=diff ============================================================================== --- llvm/trunk/README.txt (original) +++ llvm/trunk/README.txt Tue Nov 22 14:03:30 2011 @@ -13,4 +13,4 @@ assistance with LLVM. If you're writing a package for LLVM, see docs/Packaging.html for our -suggestions. +suggestions. From adasgupt at codeaurora.org Tue Nov 22 14:05:48 2011 From: adasgupt at codeaurora.org (Anshuman Dasgupta) Date: Tue, 22 Nov 2011 20:05:48 -0000 Subject: [llvm-commits] [llvm] r145079 - /llvm/trunk/README.txt Message-ID: <20111122200548.AE8B42A6C134@llvm.org> Author: adasgupt Date: Tue Nov 22 14:05:48 2011 New Revision: 145079 URL: http://llvm.org/viewvc/llvm-project?rev=145079&view=rev Log: Undo test commit Modified: llvm/trunk/README.txt Modified: llvm/trunk/README.txt URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/README.txt?rev=145079&r1=145078&r2=145079&view=diff ============================================================================== --- llvm/trunk/README.txt (original) +++ llvm/trunk/README.txt Tue Nov 22 14:05:48 2011 @@ -13,4 +13,4 @@ assistance with LLVM. If you're writing a package for LLVM, see docs/Packaging.html for our -suggestions. +suggestions. From jan_sjodin at yahoo.com Tue Nov 22 16:47:58 2011 From: jan_sjodin at yahoo.com (Jan Sjodin) Date: Tue, 22 Nov 2011 14:47:58 -0800 (PST) Subject: [llvm-commits] Initial patch for FMA4 support Message-ID: <1322002078.40338.YahooMailNeo@web161508.mail.bf1.yahoo.com> This patch contains support for encoding FMA4 instructions and tablegen patterns for scalar FMA4 operations and an intrinsic and tests for vfmaddsd. - Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20111122/e64176d6/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: 0053_fma4.patch Type: application/octet-stream Size: 11859 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20111122/e64176d6/attachment.obj From kcc at google.com Tue Nov 22 20:10:54 2011 From: kcc at google.com (Kostya Serebryany) Date: Wed, 23 Nov 2011 02:10:54 -0000 Subject: [llvm-commits] [llvm] r145092 - in /llvm/trunk: lib/Transforms/Instrumentation/AddressSanitizer.cpp test/Instrumentation/AddressSanitizer/do-not-touch-threadlocal.ll Message-ID: <20111123021054.4FDEC2A6C134@llvm.org> Author: kcc Date: Tue Nov 22 20:10:54 2011 New Revision: 145092 URL: http://llvm.org/viewvc/llvm-project?rev=145092&view=rev Log: [asan] do not instrument threadlocal globals, this is buggy Added: llvm/trunk/test/Instrumentation/AddressSanitizer/do-not-touch-threadlocal.ll Modified: llvm/trunk/lib/Transforms/Instrumentation/AddressSanitizer.cpp Modified: llvm/trunk/lib/Transforms/Instrumentation/AddressSanitizer.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Transforms/Instrumentation/AddressSanitizer.cpp?rev=145092&r1=145091&r2=145092&view=diff ============================================================================== --- llvm/trunk/lib/Transforms/Instrumentation/AddressSanitizer.cpp (original) +++ llvm/trunk/lib/Transforms/Instrumentation/AddressSanitizer.cpp Tue Nov 22 20:10:54 2011 @@ -455,6 +455,11 @@ G->getLinkage() != GlobalVariable::PrivateLinkage && G->getLinkage() != GlobalVariable::InternalLinkage) continue; + // Two problems with thread-locals: + // - The address of the main thread's copy can't be computed at link-time. + // - Need to poison all copies, not just the main thread's one. + if (G->isThreadLocal()) + continue; // For now, just ignore this Alloca if the alignment is large. if (G->getAlignment() > RedzoneSize) continue; @@ -787,6 +792,7 @@ // Workaround for bug 11395: we don't want to instrument stack in functions // with large assembly blobs (32-bit only), otherwise reg alloc may crash. +// FIXME: remove once the bug 11395 is fixed. bool AddressSanitizer::LooksLikeCodeInBug11395(Instruction *I) { if (LongSize != 32) return false; CallInst *CI = dyn_cast(I); Added: llvm/trunk/test/Instrumentation/AddressSanitizer/do-not-touch-threadlocal.ll URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Instrumentation/AddressSanitizer/do-not-touch-threadlocal.ll?rev=145092&view=auto ============================================================================== --- llvm/trunk/test/Instrumentation/AddressSanitizer/do-not-touch-threadlocal.ll (added) +++ llvm/trunk/test/Instrumentation/AddressSanitizer/do-not-touch-threadlocal.ll Tue Nov 22 20:10:54 2011 @@ -0,0 +1,6 @@ +; RUN: opt < %s -asan -S | FileCheck %s +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-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64" +target triple = "x86_64-unknown-linux-gnu" +; no action should be taken for thread locals + at xxx = thread_local global i32 0, align 4 +; CHECK-NOT: __asan_register_globals From chandlerc at gmail.com Tue Nov 22 21:03:21 2011 From: chandlerc at gmail.com (Chandler Carruth) Date: Wed, 23 Nov 2011 03:03:21 -0000 Subject: [llvm-commits] [llvm] r145094 - in /llvm/trunk: lib/CodeGen/MachineBlockPlacement.cpp test/CodeGen/X86/block-placement.ll Message-ID: <20111123030322.0A4C12A6C134@llvm.org> Author: chandlerc Date: Tue Nov 22 21:03:21 2011 New Revision: 145094 URL: http://llvm.org/viewvc/llvm-project?rev=145094&view=rev Log: Fix a crash in block placement due to an inner loop that happened to be reversed in the function's original ordering, and we happened to encounter it while handling an outer unnatural CFG structure. Thanks to the test case reduced from GCC's source by Benjamin Kramer. This may also fix a crasher in gzip that Duncan reduced for me, but I haven't yet gotten to testing that one. Modified: llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp llvm/trunk/test/CodeGen/X86/block-placement.ll Modified: llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp?rev=145094&r1=145093&r2=145094&view=diff ============================================================================== --- llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp (original) +++ llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp Tue Nov 22 21:03:21 2011 @@ -488,7 +488,10 @@ continue; if (BlockToChain[I] != &PlacedChain) { PrevUnplacedBlockIt = I; - return I; + // Now select the head of the chain to which the unplaced block belongs + // as the block to place. This will force the entire chain to be placed, + // and satisfies the requirements of merging chains. + return *BlockToChain[I]->begin(); } } return 0; Modified: llvm/trunk/test/CodeGen/X86/block-placement.ll URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/block-placement.ll?rev=145094&r1=145093&r2=145094&view=diff ============================================================================== --- llvm/trunk/test/CodeGen/X86/block-placement.ll (original) +++ llvm/trunk/test/CodeGen/X86/block-placement.ll Tue Nov 22 21:03:21 2011 @@ -503,3 +503,44 @@ loop: br label %loop } + +define void @test_unnatural_cfg_backwards_inner_loop() { +; Test that when we encounter an unnatural CFG structure after having formed +; a chain for an inner loop which happened to be laid out backwards we don't +; attempt to merge onto the wrong end of the inner loop just because we find it +; first. This was reduced from a crasher in GCC's single source. +; +; CHECK: test_unnatural_cfg_backwards_inner_loop +; CHECK: %entry +; CHECK: %body +; CHECK: %loop1 +; CHECK: %loop2b +; CHECK: %loop2a + +entry: + br i1 undef, label %loop2a, label %body + +body: + br label %loop2a + +loop1: + %next.load = load i32** undef + br i1 %comp.a, label %loop2a, label %loop2b + +loop2a: + %var = phi i32* [ null, %entry ], [ null, %body ], [ %next.phi, %loop1 ] + %next.var = phi i32* [ null, %entry ], [ undef, %body ], [ %next.load, %loop1 ] + %comp.a = icmp eq i32* %var, null + br label %loop3 + +loop2b: + %gep = getelementptr inbounds i32* %var.phi, i32 0 + %next.ptr = bitcast i32* %gep to i32** + store i32* %next.phi, i32** %next.ptr + br label %loop3 + +loop3: + %var.phi = phi i32* [ %next.phi, %loop2b ], [ %var, %loop2a ] + %next.phi = phi i32* [ %next.load, %loop2b ], [ %next.var, %loop2a ] + br label %loop1 +} From rafael.espindola at gmail.com Tue Nov 22 21:07:25 2011 From: rafael.espindola at gmail.com (Rafael Espindola) Date: Wed, 23 Nov 2011 03:07:25 -0000 Subject: [llvm-commits] [llvm] r145095 - /llvm/trunk/tools/gold/Makefile Message-ID: <20111123030725.C7CF52A6C134@llvm.org> Author: rafael Date: Tue Nov 22 21:07:25 2011 New Revision: 145095 URL: http://llvm.org/viewvc/llvm-project?rev=145095&view=rev Log: Point to libLTO with -L/PATH/ -lLTO so that it is found in the install directory. Patch by Markus Trippelsdorf. Modified: llvm/trunk/tools/gold/Makefile Modified: llvm/trunk/tools/gold/Makefile URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/gold/Makefile?rev=145095&r1=145094&r2=145095&view=diff ============================================================================== --- llvm/trunk/tools/gold/Makefile (original) +++ llvm/trunk/tools/gold/Makefile Tue Nov 22 21:07:25 2011 @@ -24,6 +24,6 @@ # Because off_t is used in the public API, the largefile parts are required for # ABI compatibility. CXXFLAGS += -I$(BINUTILS_INCDIR) -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -CXXFLAGS += $(SharedLibDir)/$(SharedPrefix)LTO$(SHLIBEXT) +CXXFLAGS += -L$(SharedLibDir)/$(SharedPrefix) -lLTO include $(LEVEL)/Makefile.common From richard at metafoo.co.uk Tue Nov 22 21:21:02 2011 From: richard at metafoo.co.uk (Richard Smith) Date: Wed, 23 Nov 2011 03:21:02 -0000 (UTC) Subject: [llvm-commits] [PATCH] APInt::byteSwap always returns 0 for BitWidth > 64 Message-ID: <45416.10.0.7.180.1322018462.squirrel@webmail.secure.aluminati.net> Hi, The current implementation of APInt::byteSwap is broken for bit widths greater than 64. The attached patch fixes this. I've also switched algorithms for this case, since the previous one assumed a little-endian uint64_t. OK to commit? Thanks, Richard -------------- next part -------------- A non-text attachment was scrubbed... Name: apint-byteswap.diff Type: text/x-patch Size: 3884 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20111123/9aecc057/attachment.bin From stoklund at 2pi.dk Tue Nov 22 22:03:08 2011 From: stoklund at 2pi.dk (Jakob Stoklund Olesen) Date: Wed, 23 Nov 2011 04:03:08 -0000 Subject: [llvm-commits] [llvm] r145096 - in /llvm/trunk: lib/CodeGen/ExecutionDepsFix.cpp lib/Target/X86/X86InstrInfo.cpp test/CodeGen/X86/2011-11-22-AVX2-Domains.ll Message-ID: <20111123040308.B10A92A6C134@llvm.org> Author: stoklund Date: Tue Nov 22 22:03:08 2011 New Revision: 145096 URL: http://llvm.org/viewvc/llvm-project?rev=145096&view=rev Log: Fix PR11422. This was a bug in keeping track of the available domains when merging domain values. The wrong domain mask caused ExecutionDepsFix to try to move VANDPSYrr to the integer domain which is only available in AVX2. Also add an assertion to catch future attempts at emitting AVX2 instructions. Added: llvm/trunk/test/CodeGen/X86/2011-11-22-AVX2-Domains.ll Modified: llvm/trunk/lib/CodeGen/ExecutionDepsFix.cpp llvm/trunk/lib/Target/X86/X86InstrInfo.cpp Modified: llvm/trunk/lib/CodeGen/ExecutionDepsFix.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/ExecutionDepsFix.cpp?rev=145096&r1=145095&r2=145096&view=diff ============================================================================== --- llvm/trunk/lib/CodeGen/ExecutionDepsFix.cpp (original) +++ llvm/trunk/lib/CodeGen/ExecutionDepsFix.cpp Tue Nov 22 22:03:08 2011 @@ -600,6 +600,9 @@ while (!Regs.empty()) { if (!dv) { dv = Regs.pop_back_val().Value; + // Force the first dv to match the current instruction. + dv->AvailableDomains = dv->getCommonDomains(available); + assert(dv->AvailableDomains && "Domain should have been filtered"); continue; } @@ -617,9 +620,10 @@ } // dv is the DomainValue we are going to use for this instruction. - if (!dv) + if (!dv) { dv = alloc(); - dv->AvailableDomains = available; + dv->AvailableDomains = available; + } dv->Instrs.push_back(mi); // Finally set all defs and non-collapsed uses to dv. Modified: llvm/trunk/lib/Target/X86/X86InstrInfo.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86InstrInfo.cpp?rev=145096&r1=145095&r2=145096&view=diff ============================================================================== --- llvm/trunk/lib/Target/X86/X86InstrInfo.cpp (original) +++ llvm/trunk/lib/Target/X86/X86InstrInfo.cpp Tue Nov 22 22:03:08 2011 @@ -3606,8 +3606,11 @@ uint16_t dom = (MI->getDesc().TSFlags >> X86II::SSEDomainShift) & 3; assert(dom && "Not an SSE instruction"); const unsigned *table = lookup(MI->getOpcode(), dom); - if (!table) // try the other table + if (!table) { // try the other table + assert((TM.getSubtarget().hasAVX2() || Domain < 3) && + "256-bit vector operations only available in AVX2"); table = lookupAVX2(MI->getOpcode(), dom); + } assert(table && "Cannot change domain"); MI->setDesc(get(table[Domain-1])); } Added: llvm/trunk/test/CodeGen/X86/2011-11-22-AVX2-Domains.ll URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/2011-11-22-AVX2-Domains.ll?rev=145096&view=auto ============================================================================== --- llvm/trunk/test/CodeGen/X86/2011-11-22-AVX2-Domains.ll (added) +++ llvm/trunk/test/CodeGen/X86/2011-11-22-AVX2-Domains.ll Tue Nov 22 22:03:08 2011 @@ -0,0 +1,99 @@ +; RUN: llc < %s -mcpu=corei7-avx -mattr=+avx | FileCheck %s +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-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128" +target triple = "x86_64-apple-darwin11" + +; This test would create a vpand %ymm instruction that is only legal in AVX2. +; CHECK-NOT: vpand %ymm + +declare i32 @llvm.x86.avx.movmsk.ps.256(<8 x float>) nounwind readnone + +define void @ShadeTile() nounwind { +allocas: + br i1 undef, label %if_then, label %if_else + +if_then: ; preds = %allocas + unreachable + +if_else: ; preds = %allocas + br i1 undef, label %for_loop156.lr.ph, label %if_exit + +for_loop156.lr.ph: ; preds = %if_else + %val_6.i21244 = load i16* undef, align 2 + %0 = insertelement <8 x i16> undef, i16 %val_6.i21244, i32 6 + %val_7.i21248 = load i16* undef, align 2 + %1 = insertelement <8 x i16> %0, i16 %val_7.i21248, i32 7 + %uint2uint32.i20206 = zext <8 x i16> %1 to <8 x i32> + %bitop5.i20208 = and <8 x i32> %uint2uint32.i20206, + %bitop8.i20209 = and <8 x i32> %uint2uint32.i20206, + %bitop12.i20211 = lshr <8 x i32> %bitop5.i20208, + %binop13.i20212 = add <8 x i32> %bitop12.i20211, + %bitop15.i20213 = shl <8 x i32> %binop13.i20212, + %bitop17.i20214 = shl <8 x i32> %bitop8.i20209, + %bitop20.i20215 = or <8 x i32> undef, %bitop15.i20213 + %bitop22.i20216 = or <8 x i32> %bitop20.i20215, %bitop17.i20214 + %int_to_float_bitcast.i.i.i20217 = bitcast <8 x i32> %bitop22.i20216 to <8 x float> + %binop401 = fmul <8 x float> undef, + %binop402 = fadd <8 x float> %binop401, + %binop403 = fmul <8 x float> zeroinitializer, %binop402 + %binop406 = fmul <8 x float> %int_to_float_bitcast.i.i.i20217, + %binop407 = fadd <8 x float> %binop406, + %binop408 = fmul <8 x float> zeroinitializer, %binop407 + %binop411 = fsub <8 x float> , undef + %val_4.i21290 = load i16* undef, align 2 + %2 = insertelement <8 x i16> undef, i16 %val_4.i21290, i32 4 + %val_5.i21294 = load i16* undef, align 2 + %3 = insertelement <8 x i16> %2, i16 %val_5.i21294, i32 5 + %val_6.i21298 = load i16* undef, align 2 + %4 = insertelement <8 x i16> %3, i16 %val_6.i21298, i32 6 + %ptr_7.i21301 = inttoptr i64 undef to i16* + %val_7.i21302 = load i16* %ptr_7.i21301, align 2 + %5 = insertelement <8 x i16> %4, i16 %val_7.i21302, i32 7 + %uint2uint32.i20218 = zext <8 x i16> %5 to <8 x i32> + %structelement561 = load i8** undef, align 8 + %ptr2int563 = ptrtoint i8* %structelement561 to i64 + %smear.ptr_smear7571 = insertelement <8 x i64> undef, i64 %ptr2int563, i32 7 + %new_ptr582 = add <8 x i64> %smear.ptr_smear7571, zeroinitializer + %val_5.i21509 = load i8* null, align 1 + %6 = insertelement <8 x i8> undef, i8 %val_5.i21509, i32 5 + %7 = insertelement <8 x i8> %6, i8 undef, i32 6 + %iptr_7.i21515 = extractelement <8 x i64> %new_ptr582, i32 7 + %ptr_7.i21516 = inttoptr i64 %iptr_7.i21515 to i8* + %val_7.i21517 = load i8* %ptr_7.i21516, align 1 + %8 = insertelement <8 x i8> %7, i8 %val_7.i21517, i32 7 + %uint2float.i20245 = uitofp <8 x i8> %8 to <8 x float> + %binop.i20246 = fmul <8 x float> %uint2float.i20245, + br i1 undef, label %for_loop594.lr.ph, label %for_exit595 + +if_exit: ; preds = %if_else + ret void + +for_loop594.lr.ph: ; preds = %for_loop156.lr.ph + %bitop8.i20221 = and <8 x i32> %uint2uint32.i20218, + br i1 undef, label %cif_test_all730, label %cif_mask_mixed1552 + +for_exit595: ; preds = %for_loop156.lr.ph + unreachable + +cif_test_all730: ; preds = %for_loop594.lr.ph + %binop11.i20545 = fmul <8 x float> %binop408, zeroinitializer + %binop12.i20546 = fadd <8 x float> undef, %binop11.i20545 + %binop15.i20547 = fmul <8 x float> %binop411, undef + %binop16.i20548 = fadd <8 x float> %binop12.i20546, %binop15.i20547 + %bincmp774 = fcmp ogt <8 x float> %binop16.i20548, zeroinitializer + %val_to_boolvec32775 = sext <8 x i1> %bincmp774 to <8 x i32> + %floatmask.i20549 = bitcast <8 x i32> %val_to_boolvec32775 to <8 x float> + %v.i20550 = tail call i32 @llvm.x86.avx.movmsk.ps.256(<8 x float> %floatmask.i20549) nounwind readnone + %cond = icmp eq i32 %v.i20550, 255 + br i1 %cond, label %cif_test_all794, label %cif_test_mixed + +cif_test_all794: ; preds = %cif_test_all730 + %binop.i20572 = fmul <8 x float> %binop403, undef + unreachable + +cif_test_mixed: ; preds = %cif_test_all730 + %binop1207 = fmul <8 x float> %binop.i20246, undef + unreachable + +cif_mask_mixed1552: ; preds = %for_loop594.lr.ph + unreachable +} From bob.wilson at apple.com Wed Nov 23 01:13:57 2011 From: bob.wilson at apple.com (Bob Wilson) Date: Wed, 23 Nov 2011 07:13:57 -0000 Subject: [llvm-commits] [llvm] r145097 - in /llvm/trunk: lib/CodeGen/StackProtector.cpp test/CodeGen/X86/splat-scalar-load.ll Message-ID: <20111123071357.37B522A6C134@llvm.org> Author: bwilson Date: Wed Nov 23 01:13:56 2011 New Revision: 145097 URL: http://llvm.org/viewvc/llvm-project?rev=145097&view=rev Log: Enable stack protectors for all arrays, not just char arrays. rdar://5875909 Patch by Bill Wendling. Modified: llvm/trunk/lib/CodeGen/StackProtector.cpp llvm/trunk/test/CodeGen/X86/splat-scalar-load.ll Modified: llvm/trunk/lib/CodeGen/StackProtector.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/StackProtector.cpp?rev=145097&r1=145096&r2=145097&view=diff ============================================================================== --- llvm/trunk/lib/CodeGen/StackProtector.cpp (original) +++ llvm/trunk/lib/CodeGen/StackProtector.cpp Wed Nov 23 01:13:56 2011 @@ -123,16 +123,11 @@ // protectors. return true; - if (ArrayType *AT = dyn_cast(AI->getAllocatedType())) { - // We apparently only care about character arrays. - if (!AT->getElementType()->isIntegerTy(8)) - continue; - + if (ArrayType *AT = dyn_cast(AI->getAllocatedType())) // If an array has more than SSPBufferSize bytes of allocated space, // then we emit stack protectors. if (SSPBufferSize <= TD->getTypeAllocSize(AT)) return true; - } } } Modified: llvm/trunk/test/CodeGen/X86/splat-scalar-load.ll URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/splat-scalar-load.ll?rev=145097&r1=145096&r2=145097&view=diff ============================================================================== --- llvm/trunk/test/CodeGen/X86/splat-scalar-load.ll (original) +++ llvm/trunk/test/CodeGen/X86/splat-scalar-load.ll Wed Nov 23 01:13:56 2011 @@ -1,7 +1,7 @@ ; RUN: llc < %s -mtriple=i386-apple-darwin -mattr=+sse2 | FileCheck %s ; rdar://7434544 -define <2 x i64> @t2() nounwind ssp { +define <2 x i64> @t2() nounwind { entry: ; CHECK: t2: ; CHECK: pshufd $85, (%esp), %xmm0 From chandlerc at gmail.com Wed Nov 23 02:23:54 2011 From: chandlerc at gmail.com (Chandler Carruth) Date: Wed, 23 Nov 2011 08:23:54 -0000 Subject: [llvm-commits] [llvm] r145098 - in /llvm/trunk: lib/CodeGen/MachineBasicBlock.cpp test/CodeGen/X86/block-placement.ll Message-ID: <20111123082354.4B8612A6C134@llvm.org> Author: chandlerc Date: Wed Nov 23 02:23:54 2011 New Revision: 145098 URL: http://llvm.org/viewvc/llvm-project?rev=145098&view=rev Log: Handle the case of a no-return invoke correctly. It actually still has successors, they just are all landing pad successors. We handle this the same way as no successors. Comments attached for the next person to wade through here and another lovely test case courtesy of Benjamin Kramer's bugpoint reduction. Modified: llvm/trunk/lib/CodeGen/MachineBasicBlock.cpp llvm/trunk/test/CodeGen/X86/block-placement.ll Modified: llvm/trunk/lib/CodeGen/MachineBasicBlock.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/MachineBasicBlock.cpp?rev=145098&r1=145097&r2=145098&view=diff ============================================================================== --- llvm/trunk/lib/CodeGen/MachineBasicBlock.cpp (original) +++ llvm/trunk/lib/CodeGen/MachineBasicBlock.cpp Wed Nov 23 02:23:54 2011 @@ -305,6 +305,14 @@ assert(!TBB && "Found more than one non-landing-pad successor!"); TBB = *SI; } + + // If there is no non-landing-pad successor, the block has no + // fall-through edges to be concerned with. + if (!TBB) + return; + + // Finally update the unconditional successor to be reached via a branch + // if it would not be reached by fallthrough. if (!isLayoutSuccessor(TBB)) TII->InsertBranch(*this, TBB, 0, Cond, dl); } Modified: llvm/trunk/test/CodeGen/X86/block-placement.ll URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/block-placement.ll?rev=145098&r1=145097&r2=145098&view=diff ============================================================================== --- llvm/trunk/test/CodeGen/X86/block-placement.ll (original) +++ llvm/trunk/test/CodeGen/X86/block-placement.ll Wed Nov 23 02:23:54 2011 @@ -504,6 +504,30 @@ br label %loop } +declare void @fake_throw() noreturn + +define void @test_eh_throw() { +; For blocks containing a 'throw' (or similar functionality), we have +; a no-return invoke. In this case, only EH successors will exist, and +; fallthrough simply won't occur. Make sure we don't crash trying to update +; terminators for such constructs. +; +; CHECK: test_eh_throw +; CHECK: %entry +; CHECK: %cleanup + +entry: + invoke void @fake_throw() to label %continue unwind label %cleanup + +continue: + unreachable + +cleanup: + %0 = landingpad { i8*, i32 } personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*) + cleanup + unreachable +} + define void @test_unnatural_cfg_backwards_inner_loop() { ; Test that when we encounter an unnatural CFG structure after having formed ; a chain for an inner loop which happened to be laid out backwards we don't From nadav.rotem at intel.com Wed Nov 23 03:18:42 2011 From: nadav.rotem at intel.com (Rotem, Nadav) Date: Wed, 23 Nov 2011 11:18:42 +0200 Subject: [llvm-commits] Vectors of Pointers and Vector-GEP Message-ID: <6594DDFF12B03D4E89690887C248699402A6973563@hasmsx504.ger.corp.intel.com> Hi, Following the discussion in last week's LLVM developers conference I started working on support for vectors-of-pointers. Vectors of pointers are needed for supporting scatter/gather operations and are the first step in the direction of supporting predicated architectures. In the attached patch, I change the LLVM-IR in order to support vectors-of-pointers and added basic support for vector-gep. In following patches I plan to extend the vector-gep support to more indices and add scatter/gather intrinsics. I started by implementing vector-gep support for a simple case where there is a single index. The reason for this limitation, as noted by Dan Gohman, is that pointers may point to structs, and vectors of indices may point to different members in the struct. I am aware of the fact that supporting multiple indices is an important feature and I do intend to add support for multiple indices in the future. Please review the attached patch. Thanks, Nadav --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20111123/fe164964/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: vector_gep.patch Type: application/octet-stream Size: 14203 bytes Desc: vector_gep.patch Url : http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20111123/fe164964/attachment-0001.obj From baldrick at free.fr Wed Nov 23 03:35:40 2011 From: baldrick at free.fr (Duncan Sands) Date: Wed, 23 Nov 2011 10:35:40 +0100 Subject: [llvm-commits] Vectors of Pointers and Vector-GEP In-Reply-To: <6594DDFF12B03D4E89690887C248699402A6973563@hasmsx504.ger.corp.intel.com> References: <6594DDFF12B03D4E89690887C248699402A6973563@hasmsx504.ger.corp.intel.com> Message-ID: <4ECCBE6C.2080503@free.fr> Hi Nadav, > Following the discussion in last week?s LLVM developers conference I started > working on support for vectors-of-pointers. Vectors of pointers are needed for > supporting scatter/gather operations and are the first step in the direction of > supporting predicated architectures. In the attached patch, I change the LLVM-IR > in order to support vectors-of-pointers and added basic support for vector-gep. > In following patches I plan to extend the vector-gep support to more indices and > add scatter/gather intrinsics. one of the issues with vectors-of-pointers is then you can no longer say what the size of a vector is without target data, since you don't know what the size of a pointer is without target data. Methods like VectorType::getBitWidth will have to be deleted. Methods like VectorType::getTruncatedElementVectorType, VectorType::getExtendedElementVectorType and VectorType::getInteger will need to either be removed, or changed to take a target data parameter (which is probably a layering violation, so they would need to be moved elsewhere). The PtrToInt and IntToPtr operations will need to be enhanced to work on vectors, and a bunch of places that bitcast vectors will need to become more careful, in case they are trying to bitcast between a vector of pointers and a vector of integers. Ciao, Duncan. From elena.demikhovsky at intel.com Wed Nov 23 04:23:17 2011 From: elena.demikhovsky at intel.com (Elena Demikhovsky) Date: Wed, 23 Nov 2011 10:23:17 -0000 Subject: [llvm-commits] [llvm] r145099 - in /llvm/trunk: lib/Target/X86/X86ISelLowering.cpp test/CodeGen/X86/avx-vshufp.ll Message-ID: <20111123102317.498852A6C134@llvm.org> Author: delena Date: Wed Nov 23 04:23:16 2011 New Revision: 145099 URL: http://llvm.org/viewvc/llvm-project?rev=145099&view=rev Log: I added several lines in X86 code generator that allow to choose VSHUFPS/VSHUFPD instructions while lowering VECTOR_SHUFFLE node. I check a commuted VSHUFP mask. The patch was reviewed by Bruno. Modified: llvm/trunk/lib/Target/X86/X86ISelLowering.cpp llvm/trunk/test/CodeGen/X86/avx-vshufp.ll Modified: llvm/trunk/lib/Target/X86/X86ISelLowering.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86ISelLowering.cpp?rev=145099&r1=145098&r2=145099&view=diff ============================================================================== --- llvm/trunk/lib/Target/X86/X86ISelLowering.cpp (original) +++ llvm/trunk/lib/Target/X86/X86ISelLowering.cpp Wed Nov 23 04:23:16 2011 @@ -3431,6 +3431,41 @@ return Mask; } +/// CommuteVectorShuffleMask - Change values in a shuffle permute mask assuming +/// the two vector operands have swapped position. +static void CommuteVectorShuffleMask(SmallVectorImpl &Mask, EVT VT) { + unsigned NumElems = VT.getVectorNumElements(); + for (unsigned i = 0; i != NumElems; ++i) { + int idx = Mask[i]; + if (idx < 0) + continue; + else if (idx < (int)NumElems) + Mask[i] = idx + NumElems; + else + Mask[i] = idx - NumElems; + } +} + +/// isCommutedVSHUFP() - Return true if swapping operands will +/// allow to use the "vshufpd" or "vshufps" instruction +/// for 256-bit vectors +static bool isCommutedVSHUFPMask(const SmallVectorImpl &Mask, EVT VT, + const X86Subtarget *Subtarget) { + + unsigned NumElems = VT.getVectorNumElements(); + if ((VT.getSizeInBits() != 256) || ((NumElems != 4) && (NumElems != 8))) + return false; + + SmallVector CommutedMask; + for (unsigned i = 0; i < NumElems; ++i) + CommutedMask.push_back(Mask[i]); + + CommuteVectorShuffleMask(CommutedMask, VT); + return (NumElems == 4) ? isVSHUFPDYMask(CommutedMask, VT, Subtarget): + isVSHUFPSYMask(CommutedMask, VT, Subtarget); +} + + /// isSHUFPMask - Return true if the specified VECTOR_SHUFFLE operand /// specifies a shuffle of elements that is suitable for input to 128-bit /// SHUFPS and SHUFPD. @@ -4233,21 +4268,6 @@ SVOp->getOperand(0), &MaskVec[0]); } -/// CommuteVectorShuffleMask - Change values in a shuffle permute mask assuming -/// the two vector operands have swapped position. -static void CommuteVectorShuffleMask(SmallVectorImpl &Mask, EVT VT) { - unsigned NumElems = VT.getVectorNumElements(); - for (unsigned i = 0; i != NumElems; ++i) { - int idx = Mask[i]; - if (idx < 0) - continue; - else if (idx < (int)NumElems) - Mask[i] = idx + NumElems; - else - Mask[i] = idx - NumElems; - } -} - /// ShouldXformToMOVHLPS - Return true if the node should be transformed to /// match movhlps. The lower half elements should come from upper half of /// V1 (and in order), and the upper half elements should come from the upper @@ -6986,6 +7006,17 @@ return getTargetShuffleNode(getSHUFPOpcode(VT), dl, VT, V1, V2, getShuffleVSHUFPDYImmediate(SVOp), DAG); + // Try to swap operands in the node to match x86 shuffle ops + if (isCommutedVSHUFPMask(M, VT, Subtarget)) { + // Now we need to commute operands. + SVOp = cast(CommuteVectorShuffle(SVOp, DAG)); + V1 = SVOp->getOperand(0); + V2 = SVOp->getOperand(1); + unsigned Immediate = (NumElems == 4) ? getShuffleVSHUFPDYImmediate(SVOp): + getShuffleVSHUFPSYImmediate(SVOp); + return getTargetShuffleNode(getSHUFPOpcode(VT), dl, VT, V1, V2, Immediate, DAG); + } + //===--------------------------------------------------------------------===// // Since no target specific shuffle was selected for this generic one, // lower it into other known shuffles. FIXME: this isn't true yet, but Modified: llvm/trunk/test/CodeGen/X86/avx-vshufp.ll URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/avx-vshufp.ll?rev=145099&r1=145098&r2=145099&view=diff ============================================================================== --- llvm/trunk/test/CodeGen/X86/avx-vshufp.ll (original) +++ llvm/trunk/test/CodeGen/X86/avx-vshufp.ll Wed Nov 23 04:23:16 2011 @@ -27,3 +27,17 @@ %shuffle = shufflevector <4 x double> %a, <4 x double> %b, <4 x i32> ret <4 x double> %shuffle } + +; CHECK: vshufps $-55, %ymm +define <8 x float> @E(<8 x float> %a, <8 x float> %b) nounwind uwtable readnone ssp { +entry: + %shuffle = shufflevector <8 x float> %a, <8 x float> %b, <8 x i32> + ret <8 x float> %shuffle +} + +; CHECK: vshufpd $8, %ymm +define <4 x double> @F(<4 x double> %a, <4 x double> %b) nounwind uwtable readnone ssp { +entry: + %shuffle = shufflevector <4 x double> %a, <4 x double> %b, <4 x i32> + ret <4 x double> %shuffle +} From chandlerc at gmail.com Wed Nov 23 04:35:36 2011 From: chandlerc at gmail.com (Chandler Carruth) Date: Wed, 23 Nov 2011 10:35:36 -0000 Subject: [llvm-commits] [llvm] r145100 - in /llvm/trunk: lib/CodeGen/MachineBlockPlacement.cpp test/CodeGen/X86/block-placement.ll Message-ID: <20111123103536.466172A6C134@llvm.org> Author: chandlerc Date: Wed Nov 23 04:35:36 2011 New Revision: 145100 URL: http://llvm.org/viewvc/llvm-project?rev=145100&view=rev Log: Relax an invariant that block placement was trying to assert a bit further. This invariant just wasn't going to work in the face of unanalyzable branches; we need to be resillient to the phenomenon of chains poking into a loop and poking out of a loop. In fact, we already were, we just needed to not assert on it. This was found during a bootstrap with block placement turned on. Modified: llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp llvm/trunk/test/CodeGen/X86/block-placement.ll Modified: llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp?rev=145100&r1=145099&r2=145100&view=diff ============================================================================== --- llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp (original) +++ llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp Wed Nov 23 04:35:36 2011 @@ -504,7 +504,6 @@ const BlockFilterSet *BlockFilter) { assert(BB); assert(BlockToChain[BB] == &Chain); - assert(*Chain.begin() == BB); MachineFunction &F = *BB->getParent(); MachineFunction::iterator PrevUnplacedBlockIt = F.begin(); @@ -614,8 +613,7 @@ if (!LoopBlockSet.erase(*BCI)) { // We don't mark the loop as bad here because there are real situations // where this can occur. For example, with an unanalyzable fallthrough - // from a loop block to a non-loop block. - // FIXME: Such constructs shouldn't exist. Track them down and fix them. + // from a loop block to a non-loop block or vice versa. dbgs() << "Loop chain contains a block not contained by the loop!\n" << " Loop header: " << getBlockName(*L.block_begin()) << "\n" << " Chain header: " << getBlockName(*LoopChain.begin()) << "\n" Modified: llvm/trunk/test/CodeGen/X86/block-placement.ll URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/block-placement.ll?rev=145100&r1=145099&r2=145100&view=diff ============================================================================== --- llvm/trunk/test/CodeGen/X86/block-placement.ll (original) +++ llvm/trunk/test/CodeGen/X86/block-placement.ll Wed Nov 23 04:35:36 2011 @@ -568,3 +568,28 @@ %next.phi = phi i32* [ %next.load, %loop2b ], [ %next.var, %loop2a ] br label %loop1 } + +define void @unanalyzable_branch_to_loop_header() { +; Ensure that we can handle unanalyzable branches into loop headers. We +; pre-form chains for unanalyzable branches, and will find the tail end of that +; at the start of the loop. This function uses floating point comparison +; fallthrough because that happens to always produce unanalyzable branches on +; x86. +; +; CHECK: unanalyzable_branch_to_loop_header +; CHECK: %entry +; CHECK: %loop +; CHECK: %exit + +entry: + %cmp = fcmp une double 0.000000e+00, undef + br i1 %cmp, label %loop, label %exit + +loop: + %cond = icmp eq i8 undef, 42 + br i1 %cond, label %exit, label %loop + +exit: + ret void +} + From geek4civic at gmail.com Wed Nov 23 06:18:22 2011 From: geek4civic at gmail.com (NAKAMURA Takumi) Date: Wed, 23 Nov 2011 12:18:22 -0000 Subject: [llvm-commits] [llvm] r145101 - /llvm/trunk/test/CodeGen/X86/block-placement.ll Message-ID: <20111123121822.C0D812A6C134@llvm.org> Author: chapuni Date: Wed Nov 23 06:18:22 2011 New Revision: 145101 URL: http://llvm.org/viewvc/llvm-project?rev=145101&view=rev Log: test/CodeGen/X86/block-placement.ll: Add explicit -mtriple=i686-linux. X86 Win32 CodeGen does not support EH yet. Modified: llvm/trunk/test/CodeGen/X86/block-placement.ll Modified: llvm/trunk/test/CodeGen/X86/block-placement.ll URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/block-placement.ll?rev=145101&r1=145100&r2=145101&view=diff ============================================================================== --- llvm/trunk/test/CodeGen/X86/block-placement.ll (original) +++ llvm/trunk/test/CodeGen/X86/block-placement.ll Wed Nov 23 06:18:22 2011 @@ -1,4 +1,4 @@ -; RUN: llc -march=x86 -enable-block-placement < %s | FileCheck %s +; RUN: llc -mtriple=i686-linux -enable-block-placement < %s | FileCheck %s declare void @error(i32 %i, i32 %a, i32 %b) From hfinkel at anl.gov Wed Nov 23 07:20:36 2011 From: hfinkel at anl.gov (Hal Finkel) Date: Wed, 23 Nov 2011 07:20:36 -0600 Subject: [llvm-commits] Vectors of Pointers and Vector-GEP In-Reply-To: <6594DDFF12B03D4E89690887C248699402A6973563@hasmsx504.ger.corp.intel.com> References: <6594DDFF12B03D4E89690887C248699402A6973563@hasmsx504.ger.corp.intel.com> Message-ID: <1322054436.2507.236.camel@sapling> On Wed, 2011-11-23 at 11:18 +0200, Rotem, Nadav wrote: > Hi, > > > > Following the discussion in last week?s LLVM developers conference I > started working on support for vectors-of-pointers. Vectors of > pointers are needed for supporting scatter/gather operations and are > the first step in the direction of supporting predicated > architectures. This is also important for vanilla (auto-)vectorization. At least in the context of my basic-block autovectorizer, the fact that there is no vector GEP results in a lot of missed vectorization opportunities. -Hal > In the attached patch, I change the LLVM-IR in order to support > vectors-of-pointers and added basic support for vector-gep. In > following patches I plan to extend the vector-gep support to more > indices and add scatter/gather intrinsics. > > > > I started by implementing vector-gep support for a simple case where > there is a single index. The reason for this limitation, as noted by > Dan Gohman, is that pointers may point to structs, and vectors of > indices may point to different members in the struct. I am aware of > the fact that supporting multiple indices is an important feature and > I do intend to add support for multiple indices in the future. > > > > Please review the attached patch. > > > > Thanks, > > Nadav > > > --------------------------------------------------------------------- > Intel Israel (74) Limited > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > _______________________________________________ > llvm-commits mailing list > llvm-commits at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits -- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory From hfinkel at anl.gov Wed Nov 23 07:42:56 2011 From: hfinkel at anl.gov (Hal Finkel) Date: Wed, 23 Nov 2011 07:42:56 -0600 Subject: [llvm-commits] Vectors of Pointers and Vector-GEP In-Reply-To: <4ECCBE6C.2080503@free.fr> References: <6594DDFF12B03D4E89690887C248699402A6973563@hasmsx504.ger.corp.intel.com> <4ECCBE6C.2080503@free.fr> Message-ID: <1322055776.2507.259.camel@sapling> On Wed, 2011-11-23 at 10:35 +0100, Duncan Sands wrote: > Hi Nadav, > > > Following the discussion in last week?s LLVM developers conference I started > > working on support for vectors-of-pointers. Vectors of pointers are needed for > > supporting scatter/gather operations and are the first step in the direction of > > supporting predicated architectures. In the attached patch, I change the LLVM-IR > > in order to support vectors-of-pointers and added basic support for vector-gep. > > In following patches I plan to extend the vector-gep support to more indices and > > add scatter/gather intrinsics. > > one of the issues with vectors-of-pointers is then you can no longer say what > the size of a vector is without target data, since you don't know what the size > of a pointer is without target data. Methods like VectorType::getBitWidth will > have to be deleted. Methods like VectorType::getTruncatedElementVectorType, > VectorType::getExtendedElementVectorType and VectorType::getInteger will need to > either be removed, or changed to take a target data parameter (which is probably > a layering violation, so they would need to be moved elsewhere). The PtrToInt > and IntToPtr operations will need to be enhanced to work on vectors, and a > bunch of places that bitcast vectors will need to become more careful, in case > they are trying to bitcast between a vector of pointers and a vector of > integers. getExtendedElementVectorType, etc. don't "work" for floating-point vectors currently, so there is some precedent for this kind of thing. Another option would be to make another derived type for pointer vectors. -Hal > > Ciao, Duncan. > _______________________________________________ > llvm-commits mailing list > llvm-commits at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits -- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory From baldrick at free.fr Wed Nov 23 07:54:53 2011 From: baldrick at free.fr (Duncan Sands) Date: Wed, 23 Nov 2011 14:54:53 +0100 Subject: [llvm-commits] Vectors of Pointers and Vector-GEP In-Reply-To: <1322055776.2507.259.camel@sapling> References: <6594DDFF12B03D4E89690887C248699402A6973563@hasmsx504.ger.corp.intel.com> <4ECCBE6C.2080503@free.fr> <1322055776.2507.259.camel@sapling> Message-ID: <4ECCFB2D.5090507@free.fr> Hi Hal, > getExtendedElementVectorType, etc. don't "work" for floating-point > vectors currently, so there is some precedent for this kind of thing. I'm not sure why you think that. They are supposed to produce vectors of integers even if the original element type was a float, and as far as I can see they do. Ciao, Duncan. From benny.kra at googlemail.com Wed Nov 23 07:54:17 2011 From: benny.kra at googlemail.com (Benjamin Kramer) Date: Wed, 23 Nov 2011 13:54:17 -0000 Subject: [llvm-commits] [llvm] r145103 - in /llvm/trunk: lib/Target/X86/X86ISelLowering.cpp test/CodeGen/X86/btq.ll Message-ID: <20111123135417.D813C1BE001@llvm.org> Author: d0k Date: Wed Nov 23 07:54:17 2011 New Revision: 145103 URL: http://llvm.org/viewvc/llvm-project?rev=145103&view=rev Log: X86: Use btq for bit tests if the immediate can't be encoded in 32 bits. Before: movabsq $4294967296, %rax ## encoding: [0x48,0xb8,0x00,0x00,0x00,0x00,0x01,0x00,0x00,0x00] testq %rax, %rdi ## encoding: [0x48,0x85,0xf8] jne LBB0_2 ## encoding: [0x75,A] After: btq $32, %rdi ## encoding: [0x48,0x0f,0xba,0xe7,0x20] jb LBB0_2 ## encoding: [0x72,A] btq is usually slower than testq because it doesn't fuse with the jump, but here we're better off saving one register and a giant movabsq. Added: llvm/trunk/test/CodeGen/X86/btq.ll Modified: llvm/trunk/lib/Target/X86/X86ISelLowering.cpp Modified: llvm/trunk/lib/Target/X86/X86ISelLowering.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86ISelLowering.cpp?rev=145103&r1=145102&r2=145103&view=diff ============================================================================== --- llvm/trunk/lib/Target/X86/X86ISelLowering.cpp (original) +++ llvm/trunk/lib/Target/X86/X86ISelLowering.cpp Wed Nov 23 07:54:17 2011 @@ -8543,11 +8543,19 @@ } } else if (Op1.getOpcode() == ISD::Constant) { ConstantSDNode *AndRHS = cast(Op1); + uint64_t AndRHSVal = AndRHS->getZExtValue(); SDValue AndLHS = Op0; - if (AndRHS->getZExtValue() == 1 && AndLHS.getOpcode() == ISD::SRL) { + + if (AndRHSVal == 1 && AndLHS.getOpcode() == ISD::SRL) { LHS = AndLHS.getOperand(0); RHS = AndLHS.getOperand(1); } + + // Use BT if the immediate can't be encoded in a TEST instruction. + if (!isUInt<32>(AndRHSVal) && isPowerOf2_64(AndRHSVal)) { + LHS = AndLHS; + RHS = DAG.getConstant(Log2_64_Ceil(AndRHSVal), LHS.getValueType()); + } } if (LHS.getNode()) { Added: llvm/trunk/test/CodeGen/X86/btq.ll URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/btq.ll?rev=145103&view=auto ============================================================================== --- llvm/trunk/test/CodeGen/X86/btq.ll (added) +++ llvm/trunk/test/CodeGen/X86/btq.ll Wed Nov 23 07:54:17 2011 @@ -0,0 +1,35 @@ +; RUN: llc < %s -march=x86-64 | FileCheck %s + +declare void @bar() + +define void @test1(i64 %foo) nounwind { + %and = and i64 %foo, 4294967296 + %tobool = icmp eq i64 %and, 0 + br i1 %tobool, label %if.end, label %if.then + +; CHECK: test1: +; CHECK: btq $32 + +if.then: + tail call void @bar() nounwind + br label %if.end + +if.end: + ret void +} + +define void @test2(i64 %foo) nounwind { + %and = and i64 %foo, 2147483648 + %tobool = icmp eq i64 %and, 0 + br i1 %tobool, label %if.end, label %if.then + +; CHECK: test2: +; CHECK: testl $-2147483648 + +if.then: + tail call void @bar() nounwind + br label %if.end + +if.end: + ret void +} From hfinkel at anl.gov Wed Nov 23 08:08:56 2011 From: hfinkel at anl.gov (Hal Finkel) Date: Wed, 23 Nov 2011 08:08:56 -0600 Subject: [llvm-commits] Vectors of Pointers and Vector-GEP In-Reply-To: <4ECCFB2D.5090507@free.fr> References: <6594DDFF12B03D4E89690887C248699402A6973563@hasmsx504.ger.corp.intel.com> <4ECCBE6C.2080503@free.fr> <1322055776.2507.259.camel@sapling> <4ECCFB2D.5090507@free.fr> Message-ID: <1322057336.2507.260.camel@sapling> On Wed, 2011-11-23 at 14:54 +0100, Duncan Sands wrote: > Hi Hal, > > > getExtendedElementVectorType, etc. don't "work" for floating-point > > vectors currently, so there is some precedent for this kind of thing. > > I'm not sure why you think that. They are supposed to produce vectors > of integers even if the original element type was a float, and as far > as I can see they do. That's why I put work in quotes. They don't crash, but is that a useful behavior? -Hal > > Ciao, Duncan. -- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory From baldrick at free.fr Wed Nov 23 08:18:31 2011 From: baldrick at free.fr (Duncan Sands) Date: Wed, 23 Nov 2011 15:18:31 +0100 Subject: [llvm-commits] Vectors of Pointers and Vector-GEP In-Reply-To: <1322057336.2507.260.camel@sapling> References: <6594DDFF12B03D4E89690887C248699402A6973563@hasmsx504.ger.corp.intel.com> <4ECCBE6C.2080503@free.fr> <1322055776.2507.259.camel@sapling> <4ECCFB2D.5090507@free.fr> <1322057336.2507.260.camel@sapling> Message-ID: <4ECD00B7.4040504@free.fr> Hi Hal, >>> getExtendedElementVectorType, etc. don't "work" for floating-point >>> vectors currently, so there is some precedent for this kind of thing. >> >> I'm not sure why you think that. They are supposed to produce vectors >> of integers even if the original element type was a float, and as far >> as I can see they do. > > That's why I put work in quotes. They don't crash, but is that a useful > behavior? they're presumably useful for someone! However I don't think they should be methods on VectorType, since such methods should (IMO) be reserved for widely useful methods with a sensible universal meaning. I reckon that they should be utility functions placed somewhere else. Ciao, Duncan. > > -Hal > >> >> Ciao, Duncan. > From baldrick at free.fr Wed Nov 23 10:26:47 2011 From: baldrick at free.fr (Duncan Sands) Date: Wed, 23 Nov 2011 16:26:47 -0000 Subject: [llvm-commits] [llvm] r145104 - in /llvm/trunk: lib/Analysis/ValueTracking.cpp test/Transforms/InstSimplify/2011-11-23-MaskedBitsCrash.ll Message-ID: <20111123162647.90CC11BE001@llvm.org> Author: baldrick Date: Wed Nov 23 10:26:47 2011 New Revision: 145104 URL: http://llvm.org/viewvc/llvm-project?rev=145104&view=rev Log: Fix a crash in which a multiplication was being reported as being both negative and positive: positive, because it could be directly computed to be positive; negative, because the nsw flags means it is either negative or undefined (the multiplication always overflowed). Added: llvm/trunk/test/Transforms/InstSimplify/2011-11-23-MaskedBitsCrash.ll Modified: llvm/trunk/lib/Analysis/ValueTracking.cpp Modified: llvm/trunk/lib/Analysis/ValueTracking.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Analysis/ValueTracking.cpp?rev=145104&r1=145103&r2=145104&view=diff ============================================================================== --- llvm/trunk/lib/Analysis/ValueTracking.cpp (original) +++ llvm/trunk/lib/Analysis/ValueTracking.cpp Wed Nov 23 10:26:47 2011 @@ -248,9 +248,14 @@ APInt::getHighBitsSet(BitWidth, LeadZ); KnownZero &= Mask; - if (isKnownNonNegative) + // Only make use of no-wrap flags if we failed to compute the sign bit + // directly. This matters if the multiplication always overflows, in + // which case we prefer to follow the result of the direct computation, + // though as the program is invoking undefined behaviour we can choose + // whatever we like here. + if (isKnownNonNegative && !KnownOne.isNegative()) KnownZero.setBit(BitWidth - 1); - else if (isKnownNegative) + else if (isKnownNegative && !KnownZero.isNegative()) KnownOne.setBit(BitWidth - 1); return; Added: llvm/trunk/test/Transforms/InstSimplify/2011-11-23-MaskedBitsCrash.ll URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/InstSimplify/2011-11-23-MaskedBitsCrash.ll?rev=145104&view=auto ============================================================================== --- llvm/trunk/test/Transforms/InstSimplify/2011-11-23-MaskedBitsCrash.ll (added) +++ llvm/trunk/test/Transforms/InstSimplify/2011-11-23-MaskedBitsCrash.ll Wed Nov 23 10:26:47 2011 @@ -0,0 +1,17 @@ +; RUN: opt < %s -instsimplify + +; The mul can be proved to always overflow (turning a negative value +; into a positive one) and thus results in undefined behaviour. At +; the same time we were deducing from the nsw flag that that mul could +; be assumed to have a negative value (since if not it has an undefined +; value, which can be taken to be negative). We were reporting the mul +; as being both positive and negative, firing an assertion! +define i1 @test1(i32 %a) { +entry: + %0 = or i32 %a, 1 + %1 = shl i32 %0, 31 + %2 = mul nsw i32 %1, 4 + %3 = and i32 %2, -4 + %4 = icmp ne i32 %3, 0 + ret i1 %4 +} From hfinkel at anl.gov Wed Nov 23 10:52:37 2011 From: hfinkel at anl.gov (Hal Finkel) Date: Wed, 23 Nov 2011 10:52:37 -0600 Subject: [llvm-commits] [LLVMdev] [PATCH] BasicBlock Autovectorization Pass In-Reply-To: <1321932161.2507.101.camel@sapling> References: <1319909412.23036.851.camel@sapling> <1319914924.23036.852.camel@sapling> <1319919418.23036.881.camel@sapling> <1319928991.23036.957.camel@sapling> <1320108633.23036.1266.camel@sapling> <1320172356.23036.1298.camel@sapling> <4EB0462C.5010209@grosser.es> <1320184739.23036.1334.camel@sapling> <1320191694.23036.1497.camel@sapling> <1320749109.19359.76.camel@sapling> <4EB90E98.4010805@grosser.es> <1320762963.19359.117.camel@sapling> <4EB98207.2070807@grosser.es> <1320791390.19359.262.camel@sapling> <4EBC4B0F.6010609@grosser.es> <1321050998.19359.539.camel@sapling> <4EBDA7F9.9080709@grosser.es> <1321053083.19359.550.camel@sapling> <4EBDB1BF.7090006@grosser.es> <1321400339.19359.782.camel@sapling> <1321486739.19359.1067.camel@sapling> <4EC504B5.2020408@grosser.es> <1321898108.2507.36.camel@sapling> <1321932161.2507.101.camel@sapling> Message-ID: <1322067157.2507.263.camel@sapling> On Mon, 2011-11-21 at 21:22 -0600, Hal Finkel wrote: > On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: > > Tobias, > > > > I've attached an updated patch. It contains a few bug fixes and many > > (refactoring and coding-convention) changes inspired by your comments. > > > > I'm currently trying to fix the bug responsible for causing a compile > > failure when compiling > > test-suite/MultiSource/Applications/obsequi/toggle_move.c; after the > > pass begins to fuse instructions in a basic block in this file, the > > aliasing analysis starts producing different (more pessimistic) query > > answers. I've never before seen it do this, and I'm not sure why it is > > happening. Also odd, at the same time, the numeric labels that are > > assigned to otherwise unnamed instructions, change. I don't think I've > > seen this happen either (they generally seem to stay fixed once > > assigned). I don't know if these two things are related, but if anyone > > can provide some insight, I'd appreciate it. > > I think that I see what is happening in this case (please someone tell > me if this does not make sense). In the problematic basic block, there > are some loads and stores that are independent. The default aliasing > analysis can tell that these loads and stores don't reference the same > memory region. Then, some of the inputs to the getelementptr > instructions used for these loads and stores are fused by the > vectorization. After this happens, the aliasing analysis loses its > ability to tell that the loads and stores that make use of those > vector-calculated indices are independent. The attached patch works around this issue. Please review. Thanks again, Hal > > -Hal > > > > > In any case, this version of the patch should be much more suitable for > > your (or anyone else's) further review. > > > > Thanks again, > > Hal > > > > On Thu, 2011-11-17 at 13:57 +0100, Tobias Grosser wrote: > > > On 11/17/2011 12:38 AM, Hal Finkel wrote: > > > > Tobias, et al., > > > > > > > > Attached is the my autovectorization pass. > > > > > > Very nice. Will you be at the developer summit? Maybe we could discuss > > > the integration there? > > > > > > Here a first review of the source code. > > > > > -- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm_bb_vectorize-20111122.diff Type: text/x-patch Size: 99054 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20111123/32476f28/attachment-0001.bin From benny.kra at googlemail.com Wed Nov 23 11:58:47 2011 From: benny.kra at googlemail.com (Benjamin Kramer) Date: Wed, 23 Nov 2011 17:58:47 -0000 Subject: [llvm-commits] [llvm] r145106 - /llvm/trunk/lib/Analysis/MemoryBuiltins.cpp Message-ID: <20111123175847.D67E61BE001@llvm.org> Author: d0k Date: Wed Nov 23 11:58:47 2011 New Revision: 145106 URL: http://llvm.org/viewvc/llvm-project?rev=145106&view=rev Log: Validate the return type when checking if a function is malloc. Fixes PR11426. Not sure if a test case with a "wrong" malloc would be useful. Modified: llvm/trunk/lib/Analysis/MemoryBuiltins.cpp Modified: llvm/trunk/lib/Analysis/MemoryBuiltins.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Analysis/MemoryBuiltins.cpp?rev=145106&r1=145105&r2=145106&view=diff ============================================================================== --- llvm/trunk/lib/Analysis/MemoryBuiltins.cpp (original) +++ llvm/trunk/lib/Analysis/MemoryBuiltins.cpp Wed Nov 23 11:58:47 2011 @@ -48,10 +48,10 @@ // FIXME: workaround for PR5130, this will be obsolete when a nobuiltin // attribute will exist. FunctionType *FTy = Callee->getFunctionType(); - if (FTy->getNumParams() != 1) - return false; - return FTy->getParamType(0)->isIntegerTy(32) || - FTy->getParamType(0)->isIntegerTy(64); + return FTy->getReturnType() == Type::getInt8PtrTy(FTy->getContext()) && + FTy->getNumParams() == 1 && + (FTy->getParamType(0)->isIntegerTy(32) || + FTy->getParamType(0)->isIntegerTy(64)); } /// extractMallocCall - Returns the corresponding CallInst if the instruction From stpworld at narod.ru Wed Nov 23 12:00:42 2011 From: stpworld at narod.ru (Stepan Dyatkovskiy) Date: Wed, 23 Nov 2011 22:00:42 +0400 Subject: [llvm-commits] [LLVM, loop-unswitch] Potential bug in RewriteLoopBodyWithConditionConstant In-Reply-To: <4ECB9786.9070104@narod.ru> References: <4ECB80FC.3070307@narod.ru> <4ECB8437.9010708@free.fr> <4ECB9786.9070104@narod.ru> Message-ID: <4ECD34CA.50501@narod.ru> ping. -Stepan. Stepan Dyatkovskiy wrote: > Hi Duncan. You are right. Please find the fixed patch. > It is a pretty difficult to create a test case. By now I can only say > that after replaceUsesOfWith was invoked we implicitly proceed to > enumerate Replacement's UseList instead of LIC's. But we try to unswitch > instructions that uses both LIC and Replacement. That why all looks fine. > I also attached dumped instructions enumerated before and after fix (for > first invocation of LoopUnswitch::RewriteLoopBodyWithConditionConstant > with IsEqual = true). > .ll file that was proceed is also attached. > > -Stepan. > > Duncan Sands wrote: >> Hi Stepan, >> >>> It seems that the code inside the >>> LoopUnswitch::RewriteLoopBodyWithConditionConstant contains potential >>> bugs. >>> UseList is changed inside the loops that are goes through its items: >>> >>> LoopUnswitch.cpp, string #905: for (Value::use_iterator UI = >>> LIC->use_begin(), E >>> = LIC->use_end(); UI != E; ++UI) { >>> >>> ...and then inside the loop body UseList is changed implicitly ( >>> LoopUnswitch.cpp, string #910): >>> U->replaceUsesOfWith(LIC, Replacement); >>> >>> It seems that after editing UseList loop may produce unpreditable >>> results. But >>> we are lucky by now though :-) >>> >>> I propose to collect all to be changed and then do some changes? >>> If so, please find the patch attached for review. >> >> can you just do something like this instead? Also, do you have a >> testcase? >> >> Replacement = ConstantInt::get(Type::getInt1Ty(Val->getContext()), >> !cast(Val)->getZExtValue()); >> >> for (Value::use_iterator UI = LIC->use_begin(), E = LIC->use_end(); >> - UI != E; ++UI) { >> - Instruction *U = dyn_cast(*UI); >> + UI != E; ) { >> + Instruction *U = dyn_cast(*UI++); >> if (!U || !L->contains(U)) >> continue; >> U->replaceUsesOfWith(LIC, Replacement); >> Worklist.push_back(U); >> } >> >> Ciao, Duncan. >> _______________________________________________ >> llvm-commits mailing list >> llvm-commits at cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits > > > > _______________________________________________ > llvm-commits mailing list > llvm-commits at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits From baldrick at free.fr Wed Nov 23 12:04:55 2011 From: baldrick at free.fr (Duncan Sands) Date: Wed, 23 Nov 2011 19:04:55 +0100 Subject: [llvm-commits] [LLVM, loop-unswitch] Potential bug in RewriteLoopBodyWithConditionConstant In-Reply-To: <4ECD34CA.50501@narod.ru> References: <4ECB80FC.3070307@narod.ru> <4ECB8437.9010708@free.fr> <4ECB9786.9070104@narod.ru> <4ECD34CA.50501@narod.ru> Message-ID: <4ECD35C7.4000905@free.fr> I think Anton commented on your first patch too, but quite differently to me. Anton, are you OK with this? Ciao, Duncan. On 23/11/11 19:00, Stepan Dyatkovskiy wrote: > ping. > > -Stepan. > > Stepan Dyatkovskiy wrote: >> Hi Duncan. You are right. Please find the fixed patch. >> It is a pretty difficult to create a test case. By now I can only say >> that after replaceUsesOfWith was invoked we implicitly proceed to >> enumerate Replacement's UseList instead of LIC's. But we try to unswitch >> instructions that uses both LIC and Replacement. That why all looks fine. >> I also attached dumped instructions enumerated before and after fix (for >> first invocation of LoopUnswitch::RewriteLoopBodyWithConditionConstant >> with IsEqual = true). >> .ll file that was proceed is also attached. >> >> -Stepan. >> >> Duncan Sands wrote: >>> Hi Stepan, >>> >>>> It seems that the code inside the >>>> LoopUnswitch::RewriteLoopBodyWithConditionConstant contains potential >>>> bugs. >>>> UseList is changed inside the loops that are goes through its items: >>>> >>>> LoopUnswitch.cpp, string #905: for (Value::use_iterator UI = >>>> LIC->use_begin(), E >>>> = LIC->use_end(); UI != E; ++UI) { >>>> >>>> ...and then inside the loop body UseList is changed implicitly ( >>>> LoopUnswitch.cpp, string #910): >>>> U->replaceUsesOfWith(LIC, Replacement); >>>> >>>> It seems that after editing UseList loop may produce unpreditable >>>> results. But >>>> we are lucky by now though :-) >>>> >>>> I propose to collect all to be changed and then do some changes? >>>> If so, please find the patch attached for review. >>> >>> can you just do something like this instead? Also, do you have a >>> testcase? >>> >>> Replacement = ConstantInt::get(Type::getInt1Ty(Val->getContext()), >>> !cast(Val)->getZExtValue()); >>> >>> for (Value::use_iterator UI = LIC->use_begin(), E = LIC->use_end(); >>> - UI != E; ++UI) { >>> - Instruction *U = dyn_cast(*UI); >>> + UI != E; ) { >>> + Instruction *U = dyn_cast(*UI++); >>> if (!U || !L->contains(U)) >>> continue; >>> U->replaceUsesOfWith(LIC, Replacement); >>> Worklist.push_back(U); >>> } >>> >>> Ciao, Duncan. >>> _______________________________________________ >>> llvm-commits mailing list >>> llvm-commits at cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits >> >> >> >> _______________________________________________ >> llvm-commits mailing list >> llvm-commits at cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits > From asl at math.spbu.ru Wed Nov 23 13:01:02 2011 From: asl at math.spbu.ru (Anton Korobeynikov) Date: Wed, 23 Nov 2011 23:01:02 +0400 Subject: [llvm-commits] [LLVM, loop-unswitch] Potential bug in RewriteLoopBodyWithConditionConstant In-Reply-To: <4ECD35C7.4000905@free.fr> References: <4ECB80FC.3070307@narod.ru> <4ECB8437.9010708@free.fr> <4ECB9786.9070104@narod.ru> <4ECD34CA.50501@narod.ru> <4ECD35C7.4000905@free.fr> Message-ID: > I think Anton commented on your first patch too, but quite differently > to me. ?Anton, are you OK with this? I'm still a bit worried: we're definitely changing the list of users on-fly. Won't this invalidate the iterators? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From nicholas at mxc.ca Wed Nov 23 14:01:32 2011 From: nicholas at mxc.ca (Nick Lewycky) Date: Wed, 23 Nov 2011 12:01:32 -0800 Subject: [llvm-commits] [PATCH] APInt::byteSwap always returns 0 for BitWidth > 64 In-Reply-To: <45416.10.0.7.180.1322018462.squirrel@webmail.secure.aluminati.net> References: <45416.10.0.7.180.1322018462.squirrel@webmail.secure.aluminati.net> Message-ID: <4ECD511C.80604@mxc.ca> On 11/22/2011 07:21 PM, Richard Smith wrote: > Hi, > > The current implementation of APInt::byteSwap is broken for bit widths greater > than 64. The attached patch fixes this. I've also switched algorithms for this > case, since the previous one assumed a little-endian uint64_t. > > OK to commit? Looks good, please commit! Nick From nadav.rotem at intel.com Wed Nov 23 14:09:42 2011 From: nadav.rotem at intel.com (Rotem, Nadav) Date: Wed, 23 Nov 2011 22:09:42 +0200 Subject: [llvm-commits] Vectors of Pointers and Vector-GEP In-Reply-To: <4ECCBE6C.2080503@free.fr> References: <6594DDFF12B03D4E89690887C248699402A6973563@hasmsx504.ger.corp.intel.com> <4ECCBE6C.2080503@free.fr> Message-ID: <6594DDFF12B03D4E89690887C248699402A697390F@hasmsx504.ger.corp.intel.com> Duncan, Thanks for the quick review! Here is a short description (design) of where I am going with this patch: 1. Motivation: Vectors-of-pointers is the first step in supporting scatter/gather instructions (available in AVX2, for example). I believe that this feature was requested on the mailing list before. As mentioned by Hal Finkel earlier today, this feature is desired by autovectorizers as it simplifies the abstraction. I can also mention the Intel OpenCL Autovectorizer and ISPC as two other vectorizers which would benefit from this type. 2. The type Vectors-of-pointers is similar to the pointer type, in the sense that it cannot be bit-casted and it has no size. It supports the following conversions: a. Bitcast to other vector-of-pointers, as long as the element count is the same. b. No other bit-cast operations are allowed. 3. The type Vectors-of-pointers can be used by the following instructions: a. Insertelement/extractelement/shuffle - just like any other vector b. Getelementptr - for address calculations, with the restrictions mentioned below. c. Intrinsics - to implement the scatter/gather operations d. IntToPtr, PtrToInt - for conversion to vectors of integers [This is not implemented in this patch]. 4. The getelementptr instruction can be used to access structs, which may cause a problem for vector-geps when accessing different fields. Currently I limit the use of vector-gep to vectors of pointers with a single index. In the future, I may add support for more indices if users of the vector-gep would request for it. Matt Pharr from ISPC also requested support for vectors of arrays, which are not supported at this point. 5. The getelementptr indices must all be vectors, if the pointer operand is a vector of pointers. Regarding your specific comments, Vectors of pointers are a new type in LLVM, so I believe that any predictable and sensible behavior is acceptable. Much like pointers, 'getBitWidth' should return zero. In my current patch bitcasting of one vector pointer to another vector pointer of the same length is okay, but any other bitcast is invalid. I added an assert to getInteger to prevent calling 'getInteger' on vectors of pointers. I agree that IntToPtr and PtrToInt need to be extended in order to support vectors of pointers and I plan to add this. Thank you, Nadav -----Original Message----- From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Duncan Sands Sent: Wednesday, November 23, 2011 11:36 To: llvm-commits at cs.uiuc.edu Subject: Re: [llvm-commits] Vectors of Pointers and Vector-GEP Hi Nadav, > Following the discussion in last week's LLVM developers conference I started > working on support for vectors-of-pointers. Vectors of pointers are needed for > supporting scatter/gather operations and are the first step in the direction of > supporting predicated architectures. In the attached patch, I change the LLVM-IR > in order to support vectors-of-pointers and added basic support for vector-gep. > In following patches I plan to extend the vector-gep support to more indices and > add scatter/gather intrinsics. one of the issues with vectors-of-pointers is then you can no longer say what the size of a vector is without target data, since you don't know what the size of a pointer is without target data. Methods like VectorType::getBitWidth will have to be deleted. Methods like VectorType::getTruncatedElementVectorType, VectorType::getExtendedElementVectorType and VectorType::getInteger will need to either be removed, or changed to take a target data parameter (which is probably a layering violation, so they would need to be moved elsewhere). The PtrToInt and IntToPtr operations will need to be enhanced to work on vectors, and a bunch of places that bitcast vectors will need to become more careful, in case they are trying to bitcast between a vector of pointers and a vector of integers. Ciao, Duncan. _______________________________________________ llvm-commits mailing list llvm-commits at cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From bruno.cardoso at gmail.com Wed Nov 23 14:39:53 2011 From: bruno.cardoso at gmail.com (Bruno Cardoso Lopes) Date: Wed, 23 Nov 2011 18:39:53 -0200 Subject: [llvm-commits] Initial patch for FMA4 support In-Reply-To: <1322002078.40338.YahooMailNeo@web161508.mail.bf1.yahoo.com> References: <1322002078.40338.YahooMailNeo@web161508.mail.bf1.yahoo.com> Message-ID: Hi Jan, On Tue, Nov 22, 2011 at 8:47 PM, Jan Sjodin wrote: > This patch contains support for encoding FMA4 instructions and tablegen > patterns for scalar FMA4 operations and an intrinsic and tests for vfmaddsd. Cool! Some comments: There's no specific reason in this case to have the "Int" forms: +multiclass fma4s_Int opc, string OpcodeStr, Intrinsic Int, + PatFrag ld_frag> { ... +defm Int_VFMADDSD4 : fma4s_Int<0x6B, "vfmaddsd", int_x86_fma4_vfmadd_sd, alignedloadv2f64>; Instead, just write patterns to match the intrinsics with the previously defined FMA4 instructions. if (HasVEX_4V) ++FirstMemOp;// Skip the register source (which is encoded in VEX_VVVV). + if (HasXOP_W) + ++FirstMemOp;// Skip the register source (which is encoded in I8IMM). Use " if (HasVEX_4V || HasXOP_W)" and update the comment properly. +#include "llvm/Support/Debug.h" Are you sure you need this? + } else { + CurOp += AddrOperands + 1; + if (HasVEX_4VOp3) + ++CurOp; + } "++CurOp" lacks proper indentation! Otherwise looks great! -- Bruno Cardoso Lopes http://www.brunocardoso.cc From jan_sjodin at yahoo.com Wed Nov 23 15:24:46 2011 From: jan_sjodin at yahoo.com (Jan Sjodin) Date: Wed, 23 Nov 2011 13:24:46 -0800 (PST) Subject: [llvm-commits] Initial patch for FMA4 support In-Reply-To: References: <1322002078.40338.YahooMailNeo@web161508.mail.bf1.yahoo.com> Message-ID: <1322083486.11523.YahooMailNeo@web161518.mail.bf1.yahoo.com> Thanks Bruno for the quick review. >There's no specific reason in this case to have the "Int" forms: > >+multiclass fma4s_Int opc, string OpcodeStr, Intrinsic Int, >+??? ? ? PatFrag ld_frag> { >... >+defm Int_VFMADDSD4? : fma4s_Int<0x6B, "vfmaddsd", >int_x86_fma4_vfmadd_sd, alignedloadv2f64>; > >Instead, just write patterns to match the intrinsics with the >previously defined FMA4 instructions. Okay, will do. > >? ? ???if (HasVEX_4V) >? ? ? ???++FirstMemOp;// Skip the register source (which is encoded in >VEX_VVVV). >+? ? ? if (HasXOP_W) >+? ? ? ? ++FirstMemOp;// Skip the register source (which is encoded in I8IMM). > >Use " if (HasVEX_4V || HasXOP_W)" and update the comment properly. It actually increments twice if both VEX_4V and HasXOP_W are true, not by one. I could update the comment to make it more clear e.g.: // Skip second register source (which is encoded in I8IMM) If you want it written a different way let me know. >+#include "llvm/Support/Debug.h" > >Are you sure you need this? No, forgot to remove, will fix. > >+? ? } else { >+? ? ? CurOp += AddrOperands + 1; >+? ? ? if (HasVEX_4VOp3) >+??? ++CurOp; >+? ? } > >"++CurOp" lacks proper indentation! Will fix. - Jan From bruno.cardoso at gmail.com Wed Nov 23 15:30:12 2011 From: bruno.cardoso at gmail.com (Bruno Cardoso Lopes) Date: Wed, 23 Nov 2011 19:30:12 -0200 Subject: [llvm-commits] Initial patch for FMA4 support In-Reply-To: <1322083486.11523.YahooMailNeo@web161518.mail.bf1.yahoo.com> References: <1322002078.40338.YahooMailNeo@web161508.mail.bf1.yahoo.com> <1322083486.11523.YahooMailNeo@web161518.mail.bf1.yahoo.com> Message-ID: On Wed, Nov 23, 2011 at 7:24 PM, Jan Sjodin wrote: > Thanks Bruno for the quick review. > > >>There's no specific reason in this case to have the "Int" forms: > >> >>+multiclass fma4s_Int opc, string OpcodeStr, Intrinsic Int, >>+??? ? ? PatFrag ld_frag> { >>... >>+defm Int_VFMADDSD4? : fma4s_Int<0x6B, "vfmaddsd", >>int_x86_fma4_vfmadd_sd, alignedloadv2f64>; >> >>Instead, just write patterns to match the intrinsics with the >>previously defined FMA4 instructions. > > > Okay, will do. > > >> >>? ? ???if (HasVEX_4V) >>? ? ? ???++FirstMemOp;// Skip the register source (which is encoded in >>VEX_VVVV). >>+? ? ? if (HasXOP_W) >>+? ? ? ? ++FirstMemOp;// Skip the register source (which is encoded in I8IMM). >> >>Use " if (HasVEX_4V || HasXOP_W)" and update the comment properly. > > > It actually increments twice if both VEX_4V and HasXOP_W are true, not by one. > > I could update the comment to make it more clear e.g.: > > // Skip second register source (which is encoded in I8IMM) > > If you want it written a different way let me know. Oops. No need, it's fine this way! :) > >>+#include "llvm/Support/Debug.h" >> >>Are you sure you need this? > > No, forgot to remove, will fix. > > >> >>+? ? } else { >>+? ? ? CurOp += AddrOperands + 1; >>+? ? ? if (HasVEX_4VOp3) >>+??? ++CurOp; >>+? ? } >> >>"++CurOp" lacks proper indentation! > > Will fix. > > > - Jan > > -- Bruno Cardoso Lopes http://www.brunocardoso.cc From richard-llvm at metafoo.co.uk Wed Nov 23 15:33:37 2011 From: richard-llvm at metafoo.co.uk (Richard Smith) Date: Wed, 23 Nov 2011 21:33:37 -0000 Subject: [llvm-commits] [llvm] r145111 - in /llvm/trunk: lib/Support/APInt.cpp test/Transforms/ConstProp/bswap.ll Message-ID: <20111123213337.CB4951BE002@llvm.org> Author: rsmith Date: Wed Nov 23 15:33:37 2011 New Revision: 145111 URL: http://llvm.org/viewvc/llvm-project?rev=145111&view=rev Log: Correctly byte-swap APInts with bit-widths greater than 64. Modified: llvm/trunk/lib/Support/APInt.cpp llvm/trunk/test/Transforms/ConstProp/bswap.ll Modified: llvm/trunk/lib/Support/APInt.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Support/APInt.cpp?rev=145111&r1=145110&r2=145111&view=diff ============================================================================== --- llvm/trunk/lib/Support/APInt.cpp (original) +++ llvm/trunk/lib/Support/APInt.cpp Wed Nov 23 15:33:37 2011 @@ -870,30 +870,43 @@ return Count; } +/// Perform a logical right-shift from Src to Dst, which must be equal or +/// non-overlapping, of Words words, by Shift, which must be less than 64. +static void lshrNear(uint64_t *Dst, uint64_t *Src, unsigned Words, + unsigned Shift) { + uint64_t Carry = 0; + for (int I = Words - 1; I >= 0; --I) { + uint64_t Tmp = Src[I]; + Dst[I] = (Tmp >> Shift) | Carry; + Carry = Tmp << (64 - Shift); + } +} + APInt APInt::byteSwap() const { assert(BitWidth >= 16 && BitWidth % 16 == 0 && "Cannot byteswap!"); if (BitWidth == 16) return APInt(BitWidth, ByteSwap_16(uint16_t(VAL))); - else if (BitWidth == 32) + if (BitWidth == 32) return APInt(BitWidth, ByteSwap_32(unsigned(VAL))); - else if (BitWidth == 48) { + if (BitWidth == 48) { unsigned Tmp1 = unsigned(VAL >> 16); Tmp1 = ByteSwap_32(Tmp1); uint16_t Tmp2 = uint16_t(VAL); Tmp2 = ByteSwap_16(Tmp2); return APInt(BitWidth, (uint64_t(Tmp2) << 32) | Tmp1); - } else if (BitWidth == 64) + } + if (BitWidth == 64) return APInt(BitWidth, ByteSwap_64(VAL)); - else { - APInt Result(BitWidth, 0); - char *pByte = (char*)Result.pVal; - for (unsigned i = 0; i < BitWidth / APINT_WORD_SIZE / 2; ++i) { - char Tmp = pByte[i]; - pByte[i] = pByte[BitWidth / APINT_WORD_SIZE - 1 - i]; - pByte[BitWidth / APINT_WORD_SIZE - i - 1] = Tmp; - } - return Result; + + APInt Result(getNumWords() * APINT_BITS_PER_WORD, 0); + for (unsigned I = 0, N = getNumWords(); I != N; ++I) + Result.pVal[I] = ByteSwap_64(pVal[N - I - 1]); + if (Result.BitWidth != BitWidth) { + lshrNear(Result.pVal, Result.pVal, getNumWords(), + Result.BitWidth - BitWidth); + Result.BitWidth = BitWidth; } + return Result; } APInt llvm::APIntOps::GreatestCommonDivisor(const APInt& API1, @@ -1232,11 +1245,7 @@ // If we are shifting less than a word, compute the shift with a simple carry if (shiftAmt < APINT_BITS_PER_WORD) { - uint64_t carry = 0; - for (int i = getNumWords()-1; i >= 0; --i) { - val[i] = (pVal[i] >> shiftAmt) | carry; - carry = pVal[i] << (APINT_BITS_PER_WORD - shiftAmt); - } + lshrNear(val, pVal, getNumWords(), shiftAmt); return APInt(val, BitWidth).clearUnusedBits(); } Modified: llvm/trunk/test/Transforms/ConstProp/bswap.ll URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/ConstProp/bswap.ll?rev=145111&r1=145110&r2=145111&view=diff ============================================================================== --- llvm/trunk/test/Transforms/ConstProp/bswap.ll (original) +++ llvm/trunk/test/Transforms/ConstProp/bswap.ll Wed Nov 23 15:33:37 2011 @@ -1,6 +1,6 @@ ; bswap should be constant folded when it is passed a constant argument -; RUN: opt < %s -constprop -S | not grep call +; RUN: opt < %s -constprop -S | FileCheck %s declare i16 @llvm.bswap.i16(i16) @@ -8,18 +8,34 @@ declare i64 @llvm.bswap.i64(i64) +declare i80 @llvm.bswap.i80(i80) + +; CHECK: define i16 @W define i16 @W() { + ; CHECK: ret i16 256 %Z = call i16 @llvm.bswap.i16( i16 1 ) ; [#uses=1] ret i16 %Z } +; CHECK: define i32 @X define i32 @X() { + ; CHECK: ret i32 16777216 %Z = call i32 @llvm.bswap.i32( i32 1 ) ; [#uses=1] ret i32 %Z } +; CHECK: define i64 @Y define i64 @Y() { + ; CHECK: ret i64 72057594037927936 %Z = call i64 @llvm.bswap.i64( i64 1 ) ; [#uses=1] ret i64 %Z } +; CHECK: define i80 @Z +define i80 @Z() { + ; CHECK: ret i80 -450681596205739728166896 + ; 0xA0908070605040302010 + %Z = call i80 @llvm.bswap.i80( i80 76151636403560493650080 ) + ; 0x102030405060708090A0 + ret i80 %Z +} From richard at metafoo.co.uk Wed Nov 23 15:37:11 2011 From: richard at metafoo.co.uk (Richard Smith) Date: Wed, 23 Nov 2011 21:37:11 -0000 (UTC) Subject: [llvm-commits] [PATCH] APInt::byteSwap always returns 0 for BitWidth > 64 In-Reply-To: <4ECD511C.80604@mxc.ca> References: <45416.10.0.7.180.1322018462.squirrel@webmail.secure.aluminati.net> <4ECD511C.80604@mxc.ca> Message-ID: <48870.10.0.7.178.1322084231.squirrel@webmail.secure.aluminati.net> On Wed, November 23, 2011 20:01, Nick Lewycky wrote: > On 11/22/2011 07:21 PM, Richard Smith wrote: >> The current implementation of APInt::byteSwap is broken for bit widths >> greater than 64. The attached patch fixes this. I've also switched >> algorithms for this case, since the previous one assumed a little-endian >> uint64_t. >> >> OK to commit? > > Looks good, please commit! Thanks, in r145111. Richard From jan_sjodin at yahoo.com Wed Nov 23 15:59:06 2011 From: jan_sjodin at yahoo.com (Jan Sjodin) Date: Wed, 23 Nov 2011 13:59:06 -0800 (PST) Subject: [llvm-commits] Initial patch for FMA4 support In-Reply-To: References: <1322002078.40338.YahooMailNeo@web161508.mail.bf1.yahoo.com> <1322083486.11523.YahooMailNeo@web161518.mail.bf1.yahoo.com> Message-ID: <1322085546.46812.YahooMailNeo@web161511.mail.bf1.yahoo.com> >>> There's no specific reason in this case to have the "Int" > forms: >> >>> >>> +multiclass fma4s_Int opc, string OpcodeStr, Intrinsic > Int, >>> +??? ? ? PatFrag ld_frag> { >>> ... >>> +defm Int_VFMADDSD4? : fma4s_Int<0x6B, "vfmaddsd", >>> int_x86_fma4_vfmadd_sd, alignedloadv2f64>; >>> >>> Instead, just write patterns to match the intrinsics with the >>> previously defined FMA4 instructions. >> >> >> Okay, will do. >> I forgot to mention, the original reason why I did this was because I did not want to write 3 patterns for each intrinsic, but I couldn't find another way to do it. In any case, I do the pattern version, since it is probably safer to keep the encoding in one place. e.g: def : Pat<(int_x86_fma4_vfmadd_sd VR128:$src1, VR128:$src2, VR128:$src3), ????????? (VFMADDSD4rr VR128:$src1, VR128:$src2, VR128:$src3)>; def : Pat<(int_x86_fma4_vfmadd_sd VR128:$src1, VR128:$src2, ????????????????????????????????? (alignedloadv2f64 addr:$src3)), ????????? (VFMADDSD4rm VR128:$src1, VR128:$src2, addr:$src3)>; def : Pat<(int_x86_fma4_vfmadd_sd VR128:$src1, (alignedloadv2f64 addr:$src2), ????????????????????????????????? VR128:$src3), ????????? (VFMADDSD4mr VR128:$src1, addr:$src2, VR128:$src3)>; - Jan From jan_sjodin at yahoo.com Wed Nov 23 16:13:18 2011 From: jan_sjodin at yahoo.com (Jan Sjodin) Date: Wed, 23 Nov 2011 14:13:18 -0800 (PST) Subject: [llvm-commits] Initial patch for FMA4 support In-Reply-To: References: <1322002078.40338.YahooMailNeo@web161508.mail.bf1.yahoo.com> <1322083486.11523.YahooMailNeo@web161518.mail.bf1.yahoo.com> Message-ID: <1322086398.5675.YahooMailNeo@web161520.mail.bf1.yahoo.com> Here is the updated patch. - Jan ----- Original Message ----- > From: Bruno Cardoso Lopes > To: Jan Sjodin > Cc: "llvm-commits at cs.uiuc.edu" > Sent: Wednesday, November 23, 2011 4:30 PM > Subject: Re: [llvm-commits] Initial patch for FMA4 support > > On Wed, Nov 23, 2011 at 7:24 PM, Jan Sjodin wrote: >> Thanks Bruno for the quick review. >> >> >>> There's no specific reason in this case to have the "Int" > forms: >> >>> >>> +multiclass fma4s_Int opc, string OpcodeStr, Intrinsic > Int, >>> +??? ? ? PatFrag ld_frag> { >>> ... >>> +defm Int_VFMADDSD4? : fma4s_Int<0x6B, "vfmaddsd", >>> int_x86_fma4_vfmadd_sd, alignedloadv2f64>; >>> >>> Instead, just write patterns to match the intrinsics with the >>> previously defined FMA4 instructions. >> >> >> Okay, will do. >> >> >>> >>> ? ? ???if (HasVEX_4V) >>> ? ? ? ???++FirstMemOp;// Skip the register source (which is encoded in >>> VEX_VVVV). >>> +? ? ? if (HasXOP_W) >>> +? ? ? ? ++FirstMemOp;// Skip the register source (which is encoded in > I8IMM). >>> >>> Use " if (HasVEX_4V || HasXOP_W)" and update the comment > properly. >> >> >> It actually increments twice if both VEX_4V and HasXOP_W are true, not by > one. >> >> I could update the comment to make it more clear e.g.: >> >> // Skip second register source (which is encoded in I8IMM) >> >> If you want it written a different way let me know. > > Oops. No need, it's fine this way! :) > >> >>> +#include "llvm/Support/Debug.h" >>> >>> Are you sure you need this? >> >> No, forgot to remove, will fix. >> >> >>> >>> +? ? } else { >>> +? ? ? CurOp += AddrOperands + 1; >>> +? ? ? if (HasVEX_4VOp3) >>> +??? ++CurOp; >>> +? ? } >>> >>> "++CurOp" lacks proper indentation! >> >> Will fix. >> >> >> - Jan >> >> > > > > -- > Bruno Cardoso Lopes > http://www.brunocardoso.cc > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0053_fma4.patch Type: application/octet-stream Size: 11017 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20111123/7c23e81b/attachment.obj From ahatanaka at mips.com Wed Nov 23 16:18:04 2011 From: ahatanaka at mips.com (Akira Hatanaka) Date: Wed, 23 Nov 2011 22:18:04 -0000 Subject: [llvm-commits] [llvm] r145112 - in /llvm/trunk: include/llvm/MC/MCFixup.h include/llvm/MC/MCObjectStreamer.h include/llvm/Support/ELF.h lib/MC/ELFObjectWriter.cpp lib/MC/ELFObjectWriter.h lib/MC/MCAsmBackend.cpp lib/MC/MCObjectStreamer.cpp lib/Target/Mips/MCTargetDesc/MipsAsmBackend.cpp Message-ID: <20111123221804.CBC992A6C12C@llvm.org> Author: ahatanak Date: Wed Nov 23 16:18:04 2011 New Revision: 145112 URL: http://llvm.org/viewvc/llvm-project?rev=145112&view=rev Log: This patch addresses gp relative fixups/relocations for jump tables. Modified: llvm/trunk/include/llvm/MC/MCFixup.h llvm/trunk/include/llvm/MC/MCObjectStreamer.h llvm/trunk/include/llvm/Support/ELF.h llvm/trunk/lib/MC/ELFObjectWriter.cpp llvm/trunk/lib/MC/ELFObjectWriter.h llvm/trunk/lib/MC/MCAsmBackend.cpp llvm/trunk/lib/MC/MCObjectStreamer.cpp llvm/trunk/lib/Target/Mips/MCTargetDesc/MipsAsmBackend.cpp Modified: llvm/trunk/include/llvm/MC/MCFixup.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/MC/MCFixup.h?rev=145112&r1=145111&r2=145112&view=diff ============================================================================== --- llvm/trunk/include/llvm/MC/MCFixup.h (original) +++ llvm/trunk/include/llvm/MC/MCFixup.h Wed Nov 23 16:18:04 2011 @@ -26,6 +26,10 @@ FK_PCRel_2, ///< A two-byte pc relative fixup. FK_PCRel_4, ///< A four-byte pc relative fixup. FK_PCRel_8, ///< A eight-byte pc relative fixup. + FK_GPRel_1, ///< A one-byte gp relative fixup. + FK_GPRel_2, ///< A two-byte gp relative fixup. + FK_GPRel_4, ///< A four-byte gp relative fixup. + FK_GPRel_8, ///< A eight-byte gp relative fixup. FirstTargetFixupKind = 128, Modified: llvm/trunk/include/llvm/MC/MCObjectStreamer.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/MC/MCObjectStreamer.h?rev=145112&r1=145111&r2=145112&view=diff ============================================================================== --- llvm/trunk/include/llvm/MC/MCObjectStreamer.h (original) +++ llvm/trunk/include/llvm/MC/MCObjectStreamer.h Wed Nov 23 16:18:04 2011 @@ -77,6 +77,7 @@ unsigned PointerSize); virtual void EmitDwarfAdvanceFrameAddr(const MCSymbol *LastLabel, const MCSymbol *Label); + virtual void EmitGPRel32Value(const MCExpr *Value); virtual void Finish(); /// @} Modified: llvm/trunk/include/llvm/Support/ELF.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Support/ELF.h?rev=145112&r1=145111&r2=145112&view=diff ============================================================================== --- llvm/trunk/include/llvm/Support/ELF.h (original) +++ llvm/trunk/include/llvm/Support/ELF.h Wed Nov 23 16:18:04 2011 @@ -599,7 +599,23 @@ R_ARM_THM_TLS_DESCSEQ32 = 0x82 }; +// Mips Specific e_flags +enum { + EF_MIPS_NOREORDER = 0x00000001, // Don't reorder instructions + EF_MIPS_PIC = 0x00000002, // Position independent code + EF_MIPS_CPIC = 0x00000004, // Call object with Position independent code + EF_MIPS_ARCH_1 = 0x00000000, // MIPS1 instruction set + EF_MIPS_ARCH_2 = 0x10000000, // MIPS2 instruction set + EF_MIPS_ARCH_3 = 0x20000000, // MIPS3 instruction set + EF_MIPS_ARCH_4 = 0x30000000, // MIPS4 instruction set + EF_MIPS_ARCH_5 = 0x40000000, // MIPS5 instruction set + EF_MIPS_ARCH_32 = 0x60000000, // MIPS32 instruction set + EF_MIPS_ARCH_32R2 = 0x70000000, // mips32r2 + EF_MIPS_ARCH = 0xf0000000 // Mask for applying EF_MIPS_ARCH_ variant +}; + // ELF Relocation types for Mips +// . enum { R_MIPS_NONE = 0, R_MIPS_16 = 1, Modified: llvm/trunk/lib/MC/ELFObjectWriter.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/MC/ELFObjectWriter.cpp?rev=145112&r1=145111&r2=145112&view=diff ============================================================================== --- llvm/trunk/lib/MC/ELFObjectWriter.cpp (original) +++ llvm/trunk/lib/MC/ELFObjectWriter.cpp Wed Nov 23 16:18:04 2011 @@ -1825,6 +1825,12 @@ MipsELFObjectWriter::~MipsELFObjectWriter() {} +// FIXME: get the real EABI Version from the Triple. +void MipsELFObjectWriter::WriteEFlags() { + Write32(ELF::EF_MIPS_NOREORDER | + ELF::EF_MIPS_ARCH_32R2); +} + unsigned MipsELFObjectWriter::GetRelocType(const MCValue &Target, const MCFixup &Fixup, bool IsPCRel, @@ -1840,6 +1846,9 @@ case FK_Data_4: Type = ELF::R_MIPS_32; break; + case FK_GPRel_4: + Type = ELF::R_MIPS_GPREL32; + break; case Mips::fixup_Mips_GPREL16: Type = ELF::R_MIPS_GPREL16; break; Modified: llvm/trunk/lib/MC/ELFObjectWriter.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/MC/ELFObjectWriter.h?rev=145112&r1=145111&r2=145112&view=diff ============================================================================== --- llvm/trunk/lib/MC/ELFObjectWriter.h (original) +++ llvm/trunk/lib/MC/ELFObjectWriter.h Wed Nov 23 16:18:04 2011 @@ -442,6 +442,8 @@ bool IsLittleEndian); virtual ~MipsELFObjectWriter(); + virtual void WriteEFlags(); + protected: virtual unsigned GetRelocType(const MCValue &Target, const MCFixup &Fixup, bool IsPCRel, bool IsRelocWithSymbol, Modified: llvm/trunk/lib/MC/MCAsmBackend.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/MC/MCAsmBackend.cpp?rev=145112&r1=145111&r2=145112&view=diff ============================================================================== --- llvm/trunk/lib/MC/MCAsmBackend.cpp (original) +++ llvm/trunk/lib/MC/MCAsmBackend.cpp Wed Nov 23 16:18:04 2011 @@ -21,14 +21,18 @@ const MCFixupKindInfo & MCAsmBackend::getFixupKindInfo(MCFixupKind Kind) const { static const MCFixupKindInfo Builtins[] = { - { "FK_Data_1", 0, 8, 0 }, - { "FK_Data_2", 0, 16, 0 }, - { "FK_Data_4", 0, 32, 0 }, - { "FK_Data_8", 0, 64, 0 }, - { "FK_PCRel_1", 0, 8, MCFixupKindInfo::FKF_IsPCRel }, + { "FK_Data_1", 0, 8, 0 }, + { "FK_Data_2", 0, 16, 0 }, + { "FK_Data_4", 0, 32, 0 }, + { "FK_Data_8", 0, 64, 0 }, + { "FK_PCRel_1", 0, 8, MCFixupKindInfo::FKF_IsPCRel }, { "FK_PCRel_2", 0, 16, MCFixupKindInfo::FKF_IsPCRel }, { "FK_PCRel_4", 0, 32, MCFixupKindInfo::FKF_IsPCRel }, - { "FK_PCRel_8", 0, 64, MCFixupKindInfo::FKF_IsPCRel } + { "FK_PCRel_8", 0, 64, MCFixupKindInfo::FKF_IsPCRel }, + { "FK_GPRel_1", 0, 8, 0 }, + { "FK_GPRel_2", 0, 16, 0 }, + { "FK_GPRel_4", 0, 32, 0 }, + { "FK_GPRel_8", 0, 64, 0 } }; assert((size_t)Kind <= sizeof(Builtins) / sizeof(Builtins[0]) && Modified: llvm/trunk/lib/MC/MCObjectStreamer.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/MC/MCObjectStreamer.cpp?rev=145112&r1=145111&r2=145112&view=diff ============================================================================== --- llvm/trunk/lib/MC/MCObjectStreamer.cpp (original) +++ llvm/trunk/lib/MC/MCObjectStreamer.cpp Wed Nov 23 16:18:04 2011 @@ -245,6 +245,16 @@ EmitFill(Res, Value, 0); } +// Associate GPRel32 fixup with data and resize data area +void MCObjectStreamer::EmitGPRel32Value(const MCExpr *Value) { + MCDataFragment *DF = getOrCreateDataFragment(); + + DF->addFixup(MCFixup::Create(DF->getContents().size(), + Value, + FK_GPRel_4)); + DF->getContents().resize(DF->getContents().size() + 4, 0); +} + void MCObjectStreamer::Finish() { // Dump out the dwarf file & directory tables and line tables. if (getContext().hasDwarfFiles()) Modified: llvm/trunk/lib/Target/Mips/MCTargetDesc/MipsAsmBackend.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/Mips/MCTargetDesc/MipsAsmBackend.cpp?rev=145112&r1=145111&r2=145112&view=diff ============================================================================== --- llvm/trunk/lib/Target/Mips/MCTargetDesc/MipsAsmBackend.cpp (original) +++ llvm/trunk/lib/Target/Mips/MCTargetDesc/MipsAsmBackend.cpp Wed Nov 23 16:18:04 2011 @@ -58,6 +58,7 @@ switch (Kind) { default: break; + case FK_GPRel_4: case FK_Data_4: Value &= 0xffffffff; break; @@ -68,6 +69,9 @@ case Mips::fixup_Mips_PC16: Value &= 0x0000ffff; break; + case Mips::fixup_Mips_HI16: + Value >>= 16; + break; } return Value; @@ -104,15 +108,17 @@ llvm_unreachable("Unknown fixup kind!"); case Mips::fixup_Mips_GOT16: // This will be fixed up at link time break; + case FK_GPRel_4: case FK_Data_4: case Mips::fixup_Mips_26: case Mips::fixup_Mips_LO16: case Mips::fixup_Mips_PC16: + case Mips::fixup_Mips_HI16: // For each byte of the fragment that the fixup touches, mask i // the fixup value. The Value has been "split up" into the appr // bitfields above. for (unsigned i = 0; i != 4; ++i) // FIXME - Need to support 2 and 8 bytes - Data[Offset + i] |= uint8_t((Value >> (i * 8)) & 0xff); + Data[Offset + i] += uint8_t((Value >> (i * 8)) & 0xff); break; } } From ahatanaka at mips.com Wed Nov 23 16:19:28 2011 From: ahatanaka at mips.com (Akira Hatanaka) Date: Wed, 23 Nov 2011 22:19:28 -0000 Subject: [llvm-commits] [llvm] r145113 - in /llvm/trunk/lib/Target/Mips: MCTargetDesc/MipsMCCodeEmitter.cpp MipsAsmPrinter.cpp MipsAsmPrinter.h MipsInstrInfo.td MipsMCInstLower.cpp MipsMCInstLower.h Message-ID: <20111123221928.B8B3B2A6C12C@llvm.org> Author: ahatanak Date: Wed Nov 23 16:19:28 2011 New Revision: 145113 URL: http://llvm.org/viewvc/llvm-project?rev=145113&view=rev Log: This patch makes the following changes necessary for MIPS' direct code emission. - lower unaligned loads/stores. - encode the size operand of instructions INS and EXT. - emit relocation information needed for JAL (jump-and-link). Modified: llvm/trunk/lib/Target/Mips/MCTargetDesc/MipsMCCodeEmitter.cpp llvm/trunk/lib/Target/Mips/MipsAsmPrinter.cpp llvm/trunk/lib/Target/Mips/MipsAsmPrinter.h llvm/trunk/lib/Target/Mips/MipsInstrInfo.td llvm/trunk/lib/Target/Mips/MipsMCInstLower.cpp llvm/trunk/lib/Target/Mips/MipsMCInstLower.h Modified: llvm/trunk/lib/Target/Mips/MCTargetDesc/MipsMCCodeEmitter.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/Mips/MCTargetDesc/MipsMCCodeEmitter.cpp?rev=145113&r1=145112&r2=145113&view=diff ============================================================================== --- llvm/trunk/lib/Target/Mips/MCTargetDesc/MipsMCCodeEmitter.cpp (original) +++ llvm/trunk/lib/Target/Mips/MCTargetDesc/MipsMCCodeEmitter.cpp Wed Nov 23 16:19:28 2011 @@ -173,11 +173,21 @@ } else if (MO.isExpr()) { const MCExpr *Expr = MO.getExpr(); MCExpr::ExprKind Kind = Expr->getKind(); + unsigned Ret = 0; + + if (Kind == MCExpr::Binary) { + const MCBinaryExpr *BE = static_cast(Expr); + Expr = BE->getLHS(); + Kind = Expr->getKind(); + const MCConstantExpr *CE = dyn_cast(BE->getRHS()); + assert((Kind == MCExpr::SymbolRef) && CE && + "Binary expression must be sym+const."); + Ret = CE->getValue(); + } + if (Kind == MCExpr::SymbolRef) { - Mips::Fixups FixupKind = Mips::fixup_Mips_NONE; - MCSymbolRefExpr::VariantKind SymRefKind = - cast(Expr)->getKind(); - switch(SymRefKind) { + Mips::Fixups FixupKind; + switch(cast(Expr)->getKind()) { case MCSymbolRefExpr::VK_Mips_GPREL: FixupKind = Mips::fixup_Mips_GPREL16; break; @@ -206,12 +216,12 @@ FixupKind = Mips::fixup_Mips_TPREL_LO; break; default: - return 0; + return Ret; } // switch Fixups.push_back(MCFixup::Create(0, Expr, MCFixupKind(FixupKind))); } // if SymbolRef // All of the information is in the fixup. - return 0; + return Ret; } llvm_unreachable("Unable to encode MCOperand!"); // Not reached @@ -234,15 +244,22 @@ unsigned MipsMCCodeEmitter::getSizeExtEncoding(const MCInst &MI, unsigned OpNo, SmallVectorImpl &Fixups) const { - // FIXME: implement - return 0; + assert(MI.getOperand(OpNo).isImm()); + unsigned szEncoding = getMachineOpValue(MI, MI.getOperand(OpNo), Fixups); + return szEncoding - 1; } +// FIXME: should be called getMSBEncoding +// unsigned MipsMCCodeEmitter::getSizeInsEncoding(const MCInst &MI, unsigned OpNo, SmallVectorImpl &Fixups) const { - // FIXME: implement - return 0; + assert(MI.getOperand(OpNo-1).isImm()); + assert(MI.getOperand(OpNo).isImm()); + unsigned pos = getMachineOpValue(MI, MI.getOperand(OpNo-1), Fixups); + unsigned sz = getMachineOpValue(MI, MI.getOperand(OpNo), Fixups); + + return pos + sz - 1; } #include "MipsGenMCCodeEmitter.inc" Modified: llvm/trunk/lib/Target/Mips/MipsAsmPrinter.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/Mips/MipsAsmPrinter.cpp?rev=145113&r1=145112&r2=145113&view=diff ============================================================================== --- llvm/trunk/lib/Target/Mips/MipsAsmPrinter.cpp (original) +++ llvm/trunk/lib/Target/Mips/MipsAsmPrinter.cpp Wed Nov 23 16:19:28 2011 @@ -78,12 +78,19 @@ // Enclose unaligned load or store with .macro & .nomacro directives. if (isUnalignedLoadStore(Opc)) { - MCInst Directive; - Directive.setOpcode(Mips::MACRO); - OutStreamer.EmitInstruction(Directive); - OutStreamer.EmitInstruction(TmpInst0); - Directive.setOpcode(Mips::NOMACRO); - OutStreamer.EmitInstruction(Directive); + if (OutStreamer.hasRawTextSupport()) { + MCInst Directive; + Directive.setOpcode(Mips::MACRO); + OutStreamer.EmitInstruction(Directive); + OutStreamer.EmitInstruction(TmpInst0); + Directive.setOpcode(Mips::NOMACRO); + OutStreamer.EmitInstruction(Directive); + } else { + MCInstLowering.LowerUnalignedLoadStore(MI, MCInsts); + for (SmallVector::iterator I = MCInsts.begin(); I + != MCInsts.end(); ++I) + OutStreamer.EmitInstruction(*I); + } return; } @@ -91,8 +98,8 @@ // Lower CPLOAD and CPRESTORE if (Opc == Mips::CPLOAD) { MCInstLowering.LowerCPLOAD(MI, MCInsts); - for (SmallVector::iterator I = MCInsts.begin(); - I != MCInsts.end(); ++I) + for (SmallVector::iterator I = MCInsts.begin(); I + != MCInsts.end(); ++I) OutStreamer.EmitInstruction(*I); return; } @@ -101,7 +108,7 @@ MCInstLowering.LowerCPRESTORE(MI, TmpInst0); OutStreamer.EmitInstruction(TmpInst0); return; - } + } } OutStreamer.EmitInstruction(TmpInst0); Modified: llvm/trunk/lib/Target/Mips/MipsAsmPrinter.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/Mips/MipsAsmPrinter.h?rev=145113&r1=145112&r2=145113&view=diff ============================================================================== --- llvm/trunk/lib/Target/Mips/MipsAsmPrinter.h (original) +++ llvm/trunk/lib/Target/Mips/MipsAsmPrinter.h Wed Nov 23 16:19:28 2011 @@ -27,9 +27,11 @@ class Module; class LLVM_LIBRARY_VISIBILITY MipsAsmPrinter : public AsmPrinter { - const MipsSubtarget *Subtarget; - + public: + + const MipsSubtarget *Subtarget; + explicit MipsAsmPrinter(TargetMachine &TM, MCStreamer &Streamer) : AsmPrinter(TM, Streamer) { Subtarget = &TM.getSubtarget(); Modified: llvm/trunk/lib/Target/Mips/MipsInstrInfo.td URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/Mips/MipsInstrInfo.td?rev=145113&r1=145112&r2=145113&view=diff ============================================================================== --- llvm/trunk/lib/Target/Mips/MipsInstrInfo.td (original) +++ llvm/trunk/lib/Target/Mips/MipsInstrInfo.td Wed Nov 23 16:19:28 2011 @@ -145,7 +145,9 @@ let EncoderMethod = "getBranchTargetOpValue"; let OperandType = "OPERAND_PCREL"; } -def calltarget : Operand; +def calltarget : Operand { + let EncoderMethod = "getJumpTargetOpValue"; +} def calltarget64: Operand; def simm16 : Operand; def simm16_64 : Operand; @@ -378,6 +380,22 @@ let isPseudo = Pseudo; } +// Memory Load/Store +let canFoldAsLoad = 1 in +class LoadX op, RegisterClass RC, + Operand MemOpnd>: + FMem { +} + +class StoreX op, RegisterClass RC, + Operand MemOpnd>: + FMem { +} + // 32-bit load. multiclass LoadM32 op, string instr_asm, PatFrag OpNode, bit Pseudo = 0> { @@ -396,6 +414,13 @@ Requires<[IsN64]>; } +// 32-bit load. +multiclass LoadX32 op> { + def #NAME# : LoadX, + Requires<[NotN64]>; + def _P8 : LoadX, + Requires<[IsN64]>; +} // 32-bit store. multiclass StoreM32 op, string instr_asm, PatFrag OpNode, bit Pseudo = 0> { @@ -414,6 +439,14 @@ Requires<[IsN64]>; } +// 32-bit store. +multiclass StoreX32 op> { + def #NAME# : StoreX, + Requires<[NotN64]>; + def _P8 : StoreX, + Requires<[IsN64]>; +} + // Conditional Branch class CBranch op, string instr_asm, PatFrag cond_op, RegisterClass RC>: CBranchBase; defm USW : StoreM32<0x2b, "usw", store_u, 1>; +/// Primitives for unaligned +defm LWL : LoadX32<0x22>; +defm LWR : LoadX32<0x26>; +defm SWL : StoreX32<0x2A>; +defm SWR : StoreX32<0x2E>; + let hasSideEffects = 1 in def SYNC : MipsInst<(outs), (ins i32imm:$stype), "sync $stype", [(MipsSync imm:$stype)], NoItinerary, FrmOther> Modified: llvm/trunk/lib/Target/Mips/MipsMCInstLower.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/Mips/MipsMCInstLower.cpp?rev=145113&r1=145112&r2=145113&view=diff ============================================================================== --- llvm/trunk/lib/Target/Mips/MipsMCInstLower.cpp (original) +++ llvm/trunk/lib/Target/Mips/MipsMCInstLower.cpp Wed Nov 23 16:19:28 2011 @@ -23,6 +23,7 @@ #include "llvm/MC/MCExpr.h" #include "llvm/MC/MCInst.h" #include "llvm/Target/Mangler.h" + using namespace llvm; MipsMCInstLower::MipsMCInstLower(Mangler *mang, const MachineFunction &mf, @@ -55,34 +56,34 @@ } switch (MOTy) { - case MachineOperand::MO_MachineBasicBlock: - Symbol = MO.getMBB()->getSymbol(); - break; - - case MachineOperand::MO_GlobalAddress: - Symbol = Mang->getSymbol(MO.getGlobal()); - break; - - case MachineOperand::MO_BlockAddress: - Symbol = AsmPrinter.GetBlockAddressSymbol(MO.getBlockAddress()); - break; - - case MachineOperand::MO_ExternalSymbol: - Symbol = AsmPrinter.GetExternalSymbolSymbol(MO.getSymbolName()); - break; - - case MachineOperand::MO_JumpTableIndex: - Symbol = AsmPrinter.GetJTISymbol(MO.getIndex()); - break; - - case MachineOperand::MO_ConstantPoolIndex: - Symbol = AsmPrinter.GetCPISymbol(MO.getIndex()); - if (MO.getOffset()) - Offset += MO.getOffset(); - break; + case MachineOperand::MO_MachineBasicBlock: + Symbol = MO.getMBB()->getSymbol(); + break; + + case MachineOperand::MO_GlobalAddress: + Symbol = Mang->getSymbol(MO.getGlobal()); + break; + + case MachineOperand::MO_BlockAddress: + Symbol = AsmPrinter.GetBlockAddressSymbol(MO.getBlockAddress()); + break; + + case MachineOperand::MO_ExternalSymbol: + Symbol = AsmPrinter.GetExternalSymbolSymbol(MO.getSymbolName()); + break; + + case MachineOperand::MO_JumpTableIndex: + Symbol = AsmPrinter.GetJTISymbol(MO.getIndex()); + break; + + case MachineOperand::MO_ConstantPoolIndex: + Symbol = AsmPrinter.GetCPISymbol(MO.getIndex()); + if (MO.getOffset()) + Offset += MO.getOffset(); + break; - default: - llvm_unreachable(""); + default: + llvm_unreachable(""); } const MCSymbolRefExpr *MCSym = MCSymbolRefExpr::Create(Symbol, Kind, Ctx); @@ -145,8 +146,8 @@ OutMI.addOperand(MCOperand::CreateImm(MO.getImm())); } - -MCOperand MipsMCInstLower::LowerOperand(const MachineOperand& MO) const { +MCOperand MipsMCInstLower::LowerOperand(const MachineOperand& MO, + unsigned offset) const { MachineOperandType MOTy = MO.getType(); switch (MOTy) { @@ -158,14 +159,14 @@ if (MO.isImplicit()) break; return MCOperand::CreateReg(MO.getReg()); case MachineOperand::MO_Immediate: - return MCOperand::CreateImm(MO.getImm()); + return MCOperand::CreateImm(MO.getImm() + offset); case MachineOperand::MO_MachineBasicBlock: case MachineOperand::MO_GlobalAddress: case MachineOperand::MO_ExternalSymbol: case MachineOperand::MO_JumpTableIndex: case MachineOperand::MO_ConstantPoolIndex: case MachineOperand::MO_BlockAddress: - return LowerSymbolOperand(MO, MOTy, 0); + return LowerSymbolOperand(MO, MOTy, offset); } return MCOperand(); @@ -182,3 +183,116 @@ OutMI.addOperand(MCOp); } } + +void MipsMCInstLower::LowerUnalignedLoadStore(const MachineInstr *MI, + SmallVector& MCInsts) { + unsigned Opc = MI->getOpcode(); + MCInst instr1, instr2, instr3, move; + + bool two_instructions = false; + + assert(MI->getNumOperands() == 3); + assert(MI->getOperand(0).isReg()); + assert(MI->getOperand(1).isReg()); + + MCOperand target = LowerOperand(MI->getOperand(0)); + MCOperand base = LowerOperand(MI->getOperand(1)); + MCOperand atReg = MCOperand::CreateReg(Mips::AT); + MCOperand zeroReg = MCOperand::CreateReg(Mips::ZERO); + + MachineOperand unloweredName = MI->getOperand(2); + MCOperand name = LowerOperand(unloweredName); + + move.setOpcode(Mips::ADDu); + move.addOperand(target); + move.addOperand(atReg); + move.addOperand(zeroReg); + + switch (Opc) { + case Mips::ULW: { + // FIXME: only works for little endian right now + MCOperand adj_name = LowerOperand(unloweredName, 3); + if (base.getReg() == (target.getReg())) { + instr1.setOpcode(Mips::LWL); + instr1.addOperand(atReg); + instr1.addOperand(base); + instr1.addOperand(adj_name); + instr2.setOpcode(Mips::LWR); + instr2.addOperand(atReg); + instr2.addOperand(base); + instr2.addOperand(name); + instr3 = move; + } else { + two_instructions = true; + instr1.setOpcode(Mips::LWL); + instr1.addOperand(target); + instr1.addOperand(base); + instr1.addOperand(adj_name); + instr2.setOpcode(Mips::LWR); + instr2.addOperand(target); + instr2.addOperand(base); + instr2.addOperand(name); + } + break; + } + case Mips::ULHu: { + // FIXME: only works for little endian right now + MCOperand adj_name = LowerOperand(unloweredName, 1); + instr1.setOpcode(Mips::LBu); + instr1.addOperand(atReg); + instr1.addOperand(base); + instr1.addOperand(adj_name); + instr2.setOpcode(Mips::LBu); + instr2.addOperand(target); + instr2.addOperand(base); + instr2.addOperand(name); + instr3.setOpcode(Mips::INS); + instr3.addOperand(target); + instr3.addOperand(atReg); + instr3.addOperand(MCOperand::CreateImm(0x8)); + instr3.addOperand(MCOperand::CreateImm(0x18)); + break; + } + + case Mips::USW: { + // FIXME: only works for little endian right now + assert (base.getReg() != target.getReg()); + two_instructions = true; + MCOperand adj_name = LowerOperand(unloweredName, 3); + instr1.setOpcode(Mips::SWL); + instr1.addOperand(target); + instr1.addOperand(base); + instr1.addOperand(adj_name); + instr2.setOpcode(Mips::SWR); + instr2.addOperand(target); + instr2.addOperand(base); + instr2.addOperand(name); + break; + } + case Mips::USH: { + MCOperand adj_name = LowerOperand(unloweredName, 1); + instr1.setOpcode(Mips::SB); + instr1.addOperand(target); + instr1.addOperand(base); + instr1.addOperand(name); + instr2.setOpcode(Mips::SRL); + instr2.addOperand(atReg); + instr2.addOperand(target); + instr2.addOperand(MCOperand::CreateImm(8)); + instr3.setOpcode(Mips::SB); + instr3.addOperand(atReg); + instr3.addOperand(base); + instr3.addOperand(adj_name); + break; + } + default: + // FIXME: need to add others + assert(0 && "unaligned instruction not processed"); + } + + MCInsts.push_back(instr1); + MCInsts.push_back(instr2); + if (!two_instructions) MCInsts.push_back(instr3); +} + Modified: llvm/trunk/lib/Target/Mips/MipsMCInstLower.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/Mips/MipsMCInstLower.h?rev=145113&r1=145112&r2=145113&view=diff ============================================================================== --- llvm/trunk/lib/Target/Mips/MipsMCInstLower.h (original) +++ llvm/trunk/lib/Target/Mips/MipsMCInstLower.h Wed Nov 23 16:19:28 2011 @@ -37,10 +37,12 @@ void Lower(const MachineInstr *MI, MCInst &OutMI) const; void LowerCPLOAD(const MachineInstr *MI, SmallVector& MCInsts); void LowerCPRESTORE(const MachineInstr *MI, MCInst &OutMI); + void LowerUnalignedLoadStore(const MachineInstr *MI, + SmallVector& MCInsts); private: MCOperand LowerSymbolOperand(const MachineOperand &MO, MachineOperandType MOTy, unsigned Offset) const; - MCOperand LowerOperand(const MachineOperand& MO) const; + MCOperand LowerOperand(const MachineOperand& MO, unsigned offset = 0) const; }; } From grosbach at apple.com Wed Nov 23 18:49:21 2011 From: grosbach at apple.com (Jim Grosbach) Date: Thu, 24 Nov 2011 00:49:21 -0000 Subject: [llvm-commits] [llvm] r145118 - /llvm/trunk/docs/ReleaseNotes.html Message-ID: <20111124004921.C32FF2A6C12D@llvm.org> Author: grosbach Date: Wed Nov 23 18:49:21 2011 New Revision: 145118 URL: http://llvm.org/viewvc/llvm-project?rev=145118&view=rev Log: Add a few notes for ARM and a blurb about the MCJIT. Modified: llvm/trunk/docs/ReleaseNotes.html Modified: llvm/trunk/docs/ReleaseNotes.html URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes.html?rev=145118&r1=145117&r2=145118&view=diff ============================================================================== --- llvm/trunk/docs/ReleaseNotes.html (original) +++ llvm/trunk/docs/ReleaseNotes.html Wed Nov 23 18:49:21 2011 @@ -930,11 +930,17 @@ in.

The ELF object streamers are much more full featured.
Target dependent relocation handling has been refactored into the Targets.
Early stage MC-JIT infrastructure has been implemented.

The MC-JIT is a major new feature for MC, and will eventually grow to replace +the current JIT implementation. It emits object files direct to memory and +uses a runtime dynamic linker to resolve references and drive lazy compilation. +The MC-JIT enables much greater code reuse between the JIT and the static +compiler and provides better integration with the platform ABI as a result.

For more information, please see the Intro to the LLVM MC Project Blog Post.

@@ -994,9 +1000,9 @@

New features of the ARM target include:

Reworked Set Jump Long Jump EH Lowering,
improved support for Cortex-M series processors, and
beta quality integrated assembler support.

From chandlerc at gmail.com Thu Nov 24 02:46:04 2011 From: chandlerc at gmail.com (Chandler Carruth) Date: Thu, 24 Nov 2011 08:46:04 -0000 Subject: [llvm-commits] [llvm] r145119 - in /llvm/trunk: lib/CodeGen/MachineBlockPlacement.cpp test/CodeGen/X86/block-placement.ll Message-ID: <20111124084606.BC70D1BE002@llvm.org> Author: chandlerc Date: Thu Nov 24 02:46:04 2011 New Revision: 145119 URL: http://llvm.org/viewvc/llvm-project?rev=145119&view=rev Log: When adding blocks to the list of those which no longer have any CFG conflicts, we should only be adding the first block of the chain to the list, lest we try to merge into the middle of that chain. Most of the places we were doing this we already happened to be looking at the first block, but there is no reason to assume that, and in some cases it was clearly wrong. I've added a couple of tests here. One already worked, but I like having an explicit test for it. The other is reduced from a test case Duncan reduced for me and used to crash. Now it is handled correctly. Modified: llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp llvm/trunk/test/CodeGen/X86/block-placement.ll Modified: llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp?rev=145119&r1=145118&r2=145119&view=diff ============================================================================== --- llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp (original) +++ llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp Thu Nov 24 02:46:04 2011 @@ -315,7 +315,7 @@ // This is a cross-chain edge that is within the loop, so decrement the // loop predecessor count of the destination chain. if (SuccChain.LoopPredecessors > 0 && --SuccChain.LoopPredecessors == 0) - BlockWorkList.push_back(*SI); + BlockWorkList.push_back(*SuccChain.begin()); } } } @@ -594,7 +594,7 @@ } if (Chain.LoopPredecessors == 0) - BlockWorkList.push_back(*BI); + BlockWorkList.push_back(*Chain.begin()); } buildChain(*L.block_begin(), LoopChain, BlockWorkList, &LoopBlockSet); @@ -692,7 +692,7 @@ } if (Chain.LoopPredecessors == 0) - BlockWorkList.push_back(BB); + BlockWorkList.push_back(*Chain.begin()); } BlockChain &FunctionChain = *BlockToChain[&F.front()]; Modified: llvm/trunk/test/CodeGen/X86/block-placement.ll URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/block-placement.ll?rev=145119&r1=145118&r2=145119&view=diff ============================================================================== --- llvm/trunk/test/CodeGen/X86/block-placement.ll (original) +++ llvm/trunk/test/CodeGen/X86/block-placement.ll Thu Nov 24 02:46:04 2011 @@ -593,3 +593,59 @@ ret void } +define void @unanalyzable_branch_to_best_succ(i1 %cond) { +; Ensure that we can handle unanalyzable branches where the destination block +; gets selected as the optimal sucessor to merge. +; +; CHECK: unanalyzable_branch_to_best_succ +; CHECK: %entry +; CHECK: %foo +; CHECK: %bar +; CHECK: %exit + +entry: + ; Bias this branch toward bar to ensure we form that chain. + br i1 %cond, label %bar, label %foo, !prof !1 + +foo: + %cmp = fcmp une double 0.000000e+00, undef + br i1 %cmp, label %bar, label %exit + +bar: + call i32 @f() + br label %exit + +exit: + ret void +} + +define void @unanalyzable_branch_to_free_block(float %x) { +; Ensure that we can handle unanalyzable branches where the destination block +; gets selected as the best free block in the CFG. +; +; CHECK: unanalyzable_branch_to_free_block +; CHECK: %entry +; CHECK: %a +; CHECK: %b +; CHECK: %c +; CHECK: %exit + +entry: + br i1 undef, label %a, label %b + +a: + call i32 @f() + br label %c + +b: + %cmp = fcmp une float %x, undef + br i1 %cmp, label %c, label %exit + +c: + call i32 @g() + br label %exit + +exit: + ret void +} + From chandlerc at gmail.com Thu Nov 24 05:23:16 2011 From: chandlerc at gmail.com (Chandler Carruth) Date: Thu, 24 Nov 2011 11:23:16 -0000 Subject: [llvm-commits] [llvm] r145120 - in /llvm/trunk: lib/CodeGen/MachineBlockPlacement.cpp test/CodeGen/X86/block-placement.ll Message-ID: <20111124112316.2EC852A6C12D@llvm.org> Author: chandlerc Date: Thu Nov 24 05:23:15 2011 New Revision: 145120 URL: http://llvm.org/viewvc/llvm-project?rev=145120&view=rev Log: Fix a silly use-after-free issue. A much earlier version of this code need lots of fanciness around retaining a reference to a Chain's slot in the BlockToChain map, but that's all gone now. We can just go directly to allocating the new chain (which will update the mapping for us) and using it. Somewhat gross mechanically generated test case replicates the issue Duncan spotted when actually testing this out. Modified: llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp llvm/trunk/test/CodeGen/X86/block-placement.ll Modified: llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp?rev=145120&r1=145119&r2=145120&view=diff ============================================================================== --- llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp (original) +++ llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp Thu Nov 24 05:23:15 2011 @@ -640,8 +640,8 @@ SmallVector Cond; // For AnalyzeBranch. for (MachineFunction::iterator FI = F.begin(), FE = F.end(); FI != FE; ++FI) { MachineBasicBlock *BB = FI; - BlockChain *&Chain = BlockToChain[BB]; - Chain = new (ChainAllocator.Allocate()) BlockChain(BlockToChain, BB); + BlockChain *Chain + = new (ChainAllocator.Allocate()) BlockChain(BlockToChain, BB); // Also, merge any blocks which we cannot reason about and must preserve // the exact fallthrough behavior for. for (;;) { Modified: llvm/trunk/test/CodeGen/X86/block-placement.ll URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/block-placement.ll?rev=145120&r1=145119&r2=145120&view=diff ============================================================================== --- llvm/trunk/test/CodeGen/X86/block-placement.ll (original) +++ llvm/trunk/test/CodeGen/X86/block-placement.ll Thu Nov 24 05:23:15 2011 @@ -649,3 +649,214 @@ ret void } +define void @many_unanalyzable_branches() { +; Ensure that we don't crash as we're building up many unanalyzable branches, +; blocks, and loops. +; +; CHECK: many_unanalyzable_branches +; CHECK: %entry +; CHECK: %exit + +entry: + br label %0 + + %val0 = volatile load float* undef + %cmp0 = fcmp une float %val0, undef + br i1 %cmp0, label %1, label %0 + %val1 = volatile load float* undef + %cmp1 = fcmp une float %val1, undef + br i1 %cmp1, label %2, label %1 + %val2 = volatile load float* undef + %cmp2 = fcmp une float %val2, undef + br i1 %cmp2, label %3, label %2 + %val3 = volatile load float* undef + %cmp3 = fcmp une float %val3, undef + br i1 %cmp3, label %4, label %3 + %val4 = volatile load float* undef + %cmp4 = fcmp une float %val4, undef + br i1 %cmp4, label %5, label %4 + %val5 = volatile load float* undef + %cmp5 = fcmp une float %val5, undef + br i1 %cmp5, label %6, label %5 + %val6 = volatile load float* undef + %cmp6 = fcmp une float %val6, undef + br i1 %cmp6, label %7, label %6 + %val7 = volatile load float* undef + %cmp7 = fcmp une float %val7, undef + br i1 %cmp7, label %8, label %7 + %val8 = volatile load float* undef + %cmp8 = fcmp une float %val8, undef + br i1 %cmp8, label %9, label %8 + %val9 = volatile load float* undef + %cmp9 = fcmp une float %val9, undef + br i1 %cmp9, label %10, label %9 + %val10 = volatile load float* undef + %cmp10 = fcmp une float %val10, undef + br i1 %cmp10, label %11, label %10 + %val11 = volatile load float* undef + %cmp11 = fcmp une float %val11, undef + br i1 %cmp11, label %12, label %11 + %val12 = volatile load float* undef + %cmp12 = fcmp une float %val12, undef + br i1 %cmp12, label %13, label %12 + %val13 = volatile load float* undef + %cmp13 = fcmp une float %val13, undef + br i1 %cmp13, label %14, label %13 + %val14 = volatile load float* undef + %cmp14 = fcmp une float %val14, undef + br i1 %cmp14, label %15, label %14 + %val15 = volatile load float* undef + %cmp15 = fcmp une float %val15, undef + br i1 %cmp15, label %16, label %15 + %val16 = volatile load float* undef + %cmp16 = fcmp une float %val16, undef + br i1 %cmp16, label %17, label %16 + %val17 = volatile load float* undef + %cmp17 = fcmp une float %val17, undef + br i1 %cmp17, label %18, label %17 + %val18 = volatile load float* undef + %cmp18 = fcmp une float %val18, undef + br i1 %cmp18, label %19, label %18 + %val19 = volatile load float* undef + %cmp19 = fcmp une float %val19, undef + br i1 %cmp19, label %20, label %19 + %val20 = volatile load float* undef + %cmp20 = fcmp une float %val20, undef + br i1 %cmp20, label %21, label %20 + %val21 = volatile load float* undef + %cmp21 = fcmp une float %val21, undef + br i1 %cmp21, label %22, label %21 + %val22 = volatile load float* undef + %cmp22 = fcmp une float %val22, undef + br i1 %cmp22, label %23, label %22 + %val23 = volatile load float* undef + %cmp23 = fcmp une float %val23, undef + br i1 %cmp23, label %24, label %23 + %val24 = volatile load float* undef + %cmp24 = fcmp une float %val24, undef + br i1 %cmp24, label %25, label %24 + %val25 = volatile load float* undef + %cmp25 = fcmp une float %val25, undef + br i1 %cmp25, label %26, label %25 + %val26 = volatile load float* undef + %cmp26 = fcmp une float %val26, undef + br i1 %cmp26, label %27, label %26 + %val27 = volatile load float* undef + %cmp27 = fcmp une float %val27, undef + br i1 %cmp27, label %28, label %27 + %val28 = volatile load float* undef + %cmp28 = fcmp une float %val28, undef + br i1 %cmp28, label %29, label %28 + %val29 = volatile load float* undef + %cmp29 = fcmp une float %val29, undef + br i1 %cmp29, label %30, label %29 + %val30 = volatile load float* undef + %cmp30 = fcmp une float %val30, undef + br i1 %cmp30, label %31, label %30 + %val31 = volatile load float* undef + %cmp31 = fcmp une float %val31, undef + br i1 %cmp31, label %32, label %31 + %val32 = volatile load float* undef + %cmp32 = fcmp une float %val32, undef + br i1 %cmp32, label %33, label %32 + %val33 = volatile load float* undef + %cmp33 = fcmp une float %val33, undef + br i1 %cmp33, label %34, label %33 + %val34 = volatile load float* undef + %cmp34 = fcmp une float %val34, undef + br i1 %cmp34, label %35, label %34 + %val35 = volatile load float* undef + %cmp35 = fcmp une float %val35, undef + br i1 %cmp35, label %36, label %35 + %val36 = volatile load float* undef + %cmp36 = fcmp une float %val36, undef + br i1 %cmp36, label %37, label %36 + %val37 = volatile load float* undef + %cmp37 = fcmp une float %val37, undef + br i1 %cmp37, label %38, label %37 + %val38 = volatile load float* undef + %cmp38 = fcmp une float %val38, undef + br i1 %cmp38, label %39, label %38 + %val39 = volatile load float* undef + %cmp39 = fcmp une float %val39, undef + br i1 %cmp39, label %40, label %39 + %val40 = volatile load float* undef + %cmp40 = fcmp une float %val40, undef + br i1 %cmp40, label %41, label %40 + %val41 = volatile load float* undef + %cmp41 = fcmp une float %val41, undef + br i1 %cmp41, label %42, label %41 + %val42 = volatile load float* undef + %cmp42 = fcmp une float %val42, undef + br i1 %cmp42, label %43, label %42 + %val43 = volatile load float* undef + %cmp43 = fcmp une float %val43, undef + br i1 %cmp43, label %44, label %43 + %val44 = volatile load float* undef + %cmp44 = fcmp une float %val44, undef + br i1 %cmp44, label %45, label %44 + %val45 = volatile load float* undef + %cmp45 = fcmp une float %val45, undef + br i1 %cmp45, label %46, label %45 + %val46 = volatile load float* undef + %cmp46 = fcmp une float %val46, undef + br i1 %cmp46, label %47, label %46 + %val47 = volatile load float* undef + %cmp47 = fcmp une float %val47, undef + br i1 %cmp47, label %48, label %47 + %val48 = volatile load float* undef + %cmp48 = fcmp une float %val48, undef + br i1 %cmp48, label %49, label %48 + %val49 = volatile load float* undef + %cmp49 = fcmp une float %val49, undef + br i1 %cmp49, label %50, label %49 + %val50 = volatile load float* undef + %cmp50 = fcmp une float %val50, undef + br i1 %cmp50, label %51, label %50 + %val51 = volatile load float* undef + %cmp51 = fcmp une float %val51, undef + br i1 %cmp51, label %52, label %51 + %val52 = volatile load float* undef + %cmp52 = fcmp une float %val52, undef + br i1 %cmp52, label %53, label %52 + %val53 = volatile load float* undef + %cmp53 = fcmp une float %val53, undef + br i1 %cmp53, label %54, label %53 + %val54 = volatile load float* undef + %cmp54 = fcmp une float %val54, undef + br i1 %cmp54, label %55, label %54 + %val55 = volatile load float* undef + %cmp55 = fcmp une float %val55, undef + br i1 %cmp55, label %56, label %55 + %val56 = volatile load float* undef + %cmp56 = fcmp une float %val56, undef + br i1 %cmp56, label %57, label %56 + %val57 = volatile load float* undef + %cmp57 = fcmp une float %val57, undef + br i1 %cmp57, label %58, label %57 + %val58 = volatile load float* undef + %cmp58 = fcmp une float %val58, undef + br i1 %cmp58, label %59, label %58 + %val59 = volatile load float* undef + %cmp59 = fcmp une float %val59, undef + br i1 %cmp59, label %60, label %59 + %val60 = volatile load float* undef + %cmp60 = fcmp une float %val60, undef + br i1 %cmp60, label %61, label %60 + %val61 = volatile load float* undef + %cmp61 = fcmp une float %val61, undef + br i1 %cmp61, label %62, label %61 + %val62 = volatile load float* undef + %cmp62 = fcmp une float %val62, undef + br i1 %cmp62, label %63, label %62 + %val63 = volatile load float* undef + %cmp63 = fcmp une float %val63, undef + br i1 %cmp63, label %64, label %63 + %val64 = volatile load float* undef + %cmp64 = fcmp une float %val64, undef + br i1 %cmp64, label %65, label %64 + + br label %exit +exit: + ret void +} From nadav.rotem at intel.com Thu Nov 24 05:56:10 2011 From: nadav.rotem at intel.com (Rotem, Nadav) Date: Thu, 24 Nov 2011 13:56:10 +0200 Subject: [llvm-commits] Vectors of Pointers and Vector-GEP In-Reply-To: <6594DDFF12B03D4E89690887C248699402A697390F@hasmsx504.ger.corp.intel.com> References: <6594DDFF12B03D4E89690887C248699402A6973563@hasmsx504.ger.corp.intel.com> <4ECCBE6C.2080503@free.fr> <6594DDFF12B03D4E89690887C248699402A697390F@hasmsx504.ger.corp.intel.com> Message-ID: <6594DDFF12B03D4E89690887C248699402A6973C93@hasmsx504.ger.corp.intel.com> Ping. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Rotem, Nadav Sent: Wednesday, November 23, 2011 22:10 To: Duncan Sands; llvm-commits at cs.uiuc.edu; LLVM Developers Mailing List Subject: Re: [LLVMdev] [llvm-commits] Vectors of Pointers and Vector-GEP Duncan, Thanks for the quick review! Here is a short description (design) of where I am going with this patch: 1. Motivation: Vectors-of-pointers is the first step in supporting scatter/gather instructions (available in AVX2, for example). I believe that this feature was requested on the mailing list before. As mentioned by Hal Finkel earlier today, this feature is desired by autovectorizers as it simplifies the abstraction. I can also mention the Intel OpenCL Autovectorizer and ISPC as two other vectorizers which would benefit from this type. 2. The type Vectors-of-pointers is similar to the pointer type, in the sense that it cannot be bit-casted and it has no size. It supports the following conversions: a. Bitcast to other vector-of-pointers, as long as the element count is the same. b. No other bit-cast operations are allowed. 3. The type Vectors-of-pointers can be used by the following instructions: a. Insertelement/extractelement/shuffle - just like any other vector b. Getelementptr - for address calculations, with the restrictions mentioned below. c. Intrinsics - to implement the scatter/gather operations d. IntToPtr, PtrToInt - for conversion to vectors of integers [This is not implemented in this patch]. 4. The getelementptr instruction can be used to access structs, which may cause a problem for vector-geps when accessing different fields. Currently I limit the use of vector-gep to vectors of pointers with a single index. In the future, I may add support for more indices if users of the vector-gep would request for it. Matt Pharr from ISPC also requested support for vectors of arrays, which are not supported at this point. 5. The getelementptr indices must all be vectors, if the pointer operand is a vector of pointers. Regarding your specific comments, Vectors of pointers are a new type in LLVM, so I believe that any predictable and sensible behavior is acceptable. Much like pointers, 'getBitWidth' should return zero. In my current patch bitcasting of one vector pointer to another vector pointer of the same length is okay, but any other bitcast is invalid. I added an assert to getInteger to prevent calling 'getInteger' on vectors of pointers. I agree that IntToPtr and PtrToInt need to be extended in order to support vectors of pointers and I plan to add this. Thank you, Nadav -----Original Message----- From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Duncan Sands Sent: Wednesday, November 23, 2011 11:36 To: llvm-commits at cs.uiuc.edu Subject: Re: [llvm-commits] Vectors of Pointers and Vector-GEP Hi Nadav, > Following the discussion in last week's LLVM developers conference I started > working on support for vectors-of-pointers. Vectors of pointers are needed for > supporting scatter/gather operations and are the first step in the direction of > supporting predicated architectures. In the attached patch, I change the LLVM-IR > in order to support vectors-of-pointers and added basic support for vector-gep. > In following patches I plan to extend the vector-gep support to more indices and > add scatter/gather intrinsics. one of the issues with vectors-of-pointers is then you can no longer say what the size of a vector is without target data, since you don't know what the size of a pointer is without target data. Methods like VectorType::getBitWidth will have to be deleted. Methods like VectorType::getTruncatedElementVectorType, VectorType::getExtendedElementVectorType and VectorType::getInteger will need to either be removed, or changed to take a target data parameter (which is probably a layering violation, so they would need to be moved elsewhere). The PtrToInt and IntToPtr operations will need to be enhanced to work on vectors, and a bunch of places that bitcast vectors will need to become more careful, in case they are trying to bitcast between a vector of pointers and a vector of integers. Ciao, Duncan. _______________________________________________ llvm-commits mailing list llvm-commits at cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From benny.kra at googlemail.com Thu Nov 24 06:02:46 2011 From: benny.kra at googlemail.com (Benjamin Kramer) Date: Thu, 24 Nov 2011 12:02:46 -0000 Subject: [llvm-commits] [llvm] r145121 - in /llvm/trunk: lib/Target/X86/X86InstrInfo.td test/MC/X86/x86-64.s Message-ID: <20111124120246.F3A2B2A6C12D@llvm.org> Author: d0k Date: Thu Nov 24 06:02:46 2011 New Revision: 145121 URL: http://llvm.org/viewvc/llvm-project?rev=145121&view=rev Log: X86: alias cqo to cqto. Modified: llvm/trunk/lib/Target/X86/X86InstrInfo.td llvm/trunk/test/MC/X86/x86-64.s Modified: llvm/trunk/lib/Target/X86/X86InstrInfo.td URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86InstrInfo.td?rev=145121&r1=145120&r2=145121&view=diff ============================================================================== --- llvm/trunk/lib/Target/X86/X86InstrInfo.td (original) +++ llvm/trunk/lib/Target/X86/X86InstrInfo.td Thu Nov 24 06:02:46 2011 @@ -1523,10 +1523,11 @@ def : MnemonicAlias<"call", "callq">, Requires<[In64BitMode]>; def : MnemonicAlias<"cbw", "cbtw">; +def : MnemonicAlias<"cwde", "cwtl">; def : MnemonicAlias<"cwd", "cwtd">; def : MnemonicAlias<"cdq", "cltd">; -def : MnemonicAlias<"cwde", "cwtl">; def : MnemonicAlias<"cdqe", "cltq">; +def : MnemonicAlias<"cqo", "cqto">; // lret maps to lretl, it is not ambiguous with lretq. def : MnemonicAlias<"lret", "lretl">; Modified: llvm/trunk/test/MC/X86/x86-64.s URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/MC/X86/x86-64.s?rev=145121&r1=145120&r2=145121&view=diff ============================================================================== --- llvm/trunk/test/MC/X86/x86-64.s (original) +++ llvm/trunk/test/MC/X86/x86-64.s Thu Nov 24 06:02:46 2011 @@ -459,6 +459,7 @@ cbw // CHECK: cbtw cwd // CHECK: cwtd cdq // CHECK: cltd +cqo // CHECK: cqto // rdar://8456378 and PR7557 - fstsw fstsw %ax From hfinkel at anl.gov Thu Nov 24 08:10:13 2011 From: hfinkel at anl.gov (Hal Finkel) Date: Thu, 24 Nov 2011 08:10:13 -0600 Subject: [llvm-commits] Vectors of Pointers and Vector-GEP In-Reply-To: <6594DDFF12B03D4E89690887C248699402A697390F@hasmsx504.ger.corp.intel.com> References: <6594DDFF12B03D4E89690887C248699402A6973563@hasmsx504.ger.corp.intel.com> <4ECCBE6C.2080503@free.fr> <6594DDFF12B03D4E89690887C248699402A697390F@hasmsx504.ger.corp.intel.com> Message-ID: <1322143813.2507.429.camel@sapling> On Wed, 2011-11-23 at 22:09 +0200, Rotem, Nadav wrote: > Duncan, > > Thanks for the quick review! Here is a short description (design) of where I am going with this patch: > > 1. Motivation: Vectors-of-pointers is the first step in supporting scatter/gather instructions (available in AVX2, for example). I believe that this feature was requested on the mailing list before. As mentioned by Hal Finkel earlier today, this feature is desired by autovectorizers as it simplifies the abstraction. I can also mention the Intel OpenCL Autovectorizer and ISPC as two other vectorizers which would benefit from this type. > > 2. The type Vectors-of-pointers is similar to the pointer type, in the sense that it cannot be bit-casted and it has no size. It supports the following conversions: > a. Bitcast to other vector-of-pointers, as long as the element count is the same. > b. No other bit-cast operations are allowed. > 3. The type Vectors-of-pointers can be used by the following instructions: > a. Insertelement/extractelement/shuffle - just like any other vector > b. Getelementptr - for address calculations, with the restrictions mentioned below. > c. Intrinsics - to implement the scatter/gather operations > d. IntToPtr, PtrToInt - for conversion to vectors of integers [This is not implemented in this patch]. > 4. The getelementptr instruction can be used to access structs, which may cause a problem for vector-geps when accessing different fields. Currently I limit the use of vector-gep to vectors of pointers with a single index. In the future, I may add support for more indices if users of the vector-gep would request for it. Matt Pharr from ISPC also requested support for vectors of arrays, which are not supported at this point. So long as coverage will be incomplete, I request that you add some kind of utility function that can be called on a type and set of GEP indicies (or maybe a GEP instruction itself) to determine whether it can be vectorized. I think it would be easiest on the user if all GEPs can be vectorized. The default can just be to break up the vector GEP into some scalar GEPs and some vector insert/extracts. Regardless, this feature should really help with vectorization, and I think it is great that you're implementing it. > 5. The getelementptr indices must all be vectors, if the pointer operand is a vector of pointers. > > Regarding your specific comments, Vectors of pointers are a new type in LLVM, so I believe that any predictable and sensible behavior is acceptable. Much like pointers, 'getBitWidth' should return zero. Having getBitWidth return 0 makes sense to me. We'll need to grep the code and add or change a bunch of if statements, but I think that will be the case however we do this. -Hal > In my current patch bitcasting of one vector pointer to another vector pointer of the same length is okay, but any other bitcast is invalid. I added an assert to getInteger to prevent calling 'getInteger' on vectors of pointers. I agree that IntToPtr and PtrToInt need to be extended in order to support vectors of pointers and I plan to add this. > > Thank you, > Nadav > > > > > > -----Original Message----- > From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Duncan Sands > Sent: Wednesday, November 23, 2011 11:36 > To: llvm-commits at cs.uiuc.edu > Subject: Re: [llvm-commits] Vectors of Pointers and Vector-GEP > > Hi Nadav, > > > Following the discussion in last week's LLVM developers conference I started > > working on support for vectors-of-pointers. Vectors of pointers are needed for > > supporting scatter/gather operations and are the first step in the direction of > > supporting predicated architectures. In the attached patch, I change the LLVM-IR > > in order to support vectors-of-pointers and added basic support for vector-gep. > > In following patches I plan to extend the vector-gep support to more indices and > > add scatter/gather intrinsics. > > one of the issues with vectors-of-pointers is then you can no longer say what > the size of a vector is without target data, since you don't know what the size > of a pointer is without target data. Methods like VectorType::getBitWidth will > have to be deleted. Methods like VectorType::getTruncatedElementVectorType, > VectorType::getExtendedElementVectorType and VectorType::getInteger will need to > either be removed, or changed to take a target data parameter (which is probably > a layering violation, so they would need to be moved elsewhere). The PtrToInt > and IntToPtr operations will need to be enhanced to work on vectors, and a > bunch of places that bitcast vectors will need to become more careful, in case > they are trying to bitcast between a vector of pointers and a vector of > integers. > > Ciao, Duncan. > _______________________________________________ > llvm-commits mailing list > llvm-commits at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits > --------------------------------------------------------------------- > Intel Israel (74) Limited > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > > _______________________________________________ > llvm-commits mailing list > llvm-commits at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits -- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory From baldrick at free.fr Thu Nov 24 09:21:17 2011 From: baldrick at free.fr (Duncan Sands) Date: Thu, 24 Nov 2011 16:21:17 +0100 Subject: [llvm-commits] Vectors of Pointers and Vector-GEP In-Reply-To: <6594DDFF12B03D4E89690887C248699402A6973C93@hasmsx504.ger.corp.intel.com> References: <6594DDFF12B03D4E89690887C248699402A6973563@hasmsx504.ger.corp.intel.com> <4ECCBE6C.2080503@free.fr> <6594DDFF12B03D4E89690887C248699402A697390F@hasmsx504.ger.corp.intel.com> <6594DDFF12B03D4E89690887C248699402A6973C93@hasmsx504.ger.corp.intel.com> Message-ID: <4ECE60ED.30903@free.fr> Hi Nadav, I think Chris should at least give his blessing before you start changing the IR. Ciao, Duncan. On 24/11/11 12:56, Rotem, Nadav wrote: > Ping. > > > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Rotem, Nadav > Sent: Wednesday, November 23, 2011 22:10 > To: Duncan Sands; llvm-commits at cs.uiuc.edu; LLVM Developers Mailing List > Subject: Re: [LLVMdev] [llvm-commits] Vectors of Pointers and Vector-GEP > > Duncan, > > Thanks for the quick review! Here is a short description (design) of where I am going with this patch: > > 1. Motivation: Vectors-of-pointers is the first step in supporting scatter/gather instructions (available in AVX2, for example). I believe that this feature was requested on the mailing list before. As mentioned by Hal Finkel earlier today, this feature is desired by autovectorizers as it simplifies the abstraction. I can also mention the Intel OpenCL Autovectorizer and ISPC as two other vectorizers which would benefit from this type. > > 2. The type Vectors-of-pointers is similar to the pointer type, in the sense that it cannot be bit-casted and it has no size. It supports the following conversions: > a. Bitcast to other vector-of-pointers, as long as the element count is the same. > b. No other bit-cast operations are allowed. > 3. The type Vectors-of-pointers can be used by the following instructions: > a. Insertelement/extractelement/shuffle - just like any other vector > b. Getelementptr - for address calculations, with the restrictions mentioned below. > c. Intrinsics - to implement the scatter/gather operations > d. IntToPtr, PtrToInt - for conversion to vectors of integers [This is not implemented in this patch]. > 4. The getelementptr instruction can be used to access structs, which may cause a problem for vector-geps when accessing different fields. Currently I limit the use of vector-gep to vectors of pointers with a single index. In the future, I may add support for more indices if users of the vector-gep would request for it. Matt Pharr from ISPC also requested support for vectors of arrays, which are not supported at this point. > 5. The getelementptr indices must all be vectors, if the pointer operand is a vector of pointers. > > Regarding your specific comments, Vectors of pointers are a new type in LLVM, so I believe that any predictable and sensible behavior is acceptable. Much like pointers, 'getBitWidth' should return zero. In my current patch bitcasting of one vector pointer to another vector pointer of the same length is okay, but any other bitcast is invalid. I added an assert to getInteger to prevent calling 'getInteger' on vectors of pointers. I agree that IntToPtr and PtrToInt need to be extended in order to support vectors of pointers and I plan to add this. > > Thank you, > Nadav > > > > > > -----Original Message----- > From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Duncan Sands > Sent: Wednesday, November 23, 2011 11:36 > To: llvm-commits at cs.uiuc.edu > Subject: Re: [llvm-commits] Vectors of Pointers and Vector-GEP > > Hi Nadav, > >> Following the discussion in last week's LLVM developers conference I started >> working on support for vectors-of-pointers. Vectors of pointers are needed for >> supporting scatter/gather operations and are the first step in the direction of >> supporting predicated architectures. In the attached patch, I change the LLVM-IR >> in order to support vectors-of-pointers and added basic support for vector-gep. >> In following patches I plan to extend the vector-gep support to more indices and >> add scatter/gather intrinsics. > > one of the issues with vectors-of-pointers is then you can no longer say what > the size of a vector is without target data, since you don't know what the size > of a pointer is without target data. Methods like VectorType::getBitWidth will > have to be deleted. Methods like VectorType::getTruncatedElementVectorType, > VectorType::getExtendedElementVectorType and VectorType::getInteger will need to > either be removed, or changed to take a target data parameter (which is probably > a layering violation, so they would need to be moved elsewhere). The PtrToInt > and IntToPtr operations will need to be enhanced to work on vectors, and a > bunch of places that bitcast vectors will need to become more careful, in case > they are trying to bitcast between a vector of pointers and a vector of > integers. > > Ciao, Duncan. > _______________________________________________ > llvm-commits mailing list > llvm-commits at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits > --------------------------------------------------------------------- > Intel Israel (74) Limited > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > --------------------------------------------------------------------- > Intel Israel (74) Limited > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > > _______________________________________________ > llvm-commits mailing list > llvm-commits at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits From benny.kra at googlemail.com Thu Nov 24 11:24:33 2011 From: benny.kra at googlemail.com (Benjamin Kramer) Date: Thu, 24 Nov 2011 17:24:33 -0000 Subject: [llvm-commits] [llvm] r145122 - /llvm/trunk/lib/Support/ConstantRange.cpp Message-ID: <20111124172433.91B932A6C12D@llvm.org> Author: d0k Date: Thu Nov 24 11:24:33 2011 New Revision: 145122 URL: http://llvm.org/viewvc/llvm-project?rev=145122&view=rev Log: Make ConstantRange::truncate a bit more efficient. Modified: llvm/trunk/lib/Support/ConstantRange.cpp Modified: llvm/trunk/lib/Support/ConstantRange.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Support/ConstantRange.cpp?rev=145122&r1=145121&r2=145122&view=diff ============================================================================== --- llvm/trunk/lib/Support/ConstantRange.cpp (original) +++ llvm/trunk/lib/Support/ConstantRange.cpp Thu Nov 24 11:24:33 2011 @@ -466,10 +466,8 @@ /// correspond to the possible range of values as if the source range had been /// truncated to the specified type. ConstantRange ConstantRange::truncate(uint32_t DstTySize) const { - unsigned SrcTySize = getBitWidth(); - assert(SrcTySize > DstTySize && "Not a value truncation"); - APInt Size(APInt::getLowBitsSet(SrcTySize, DstTySize)); - if (isFullSet() || getSetSize().ugt(Size)) + assert(getBitWidth() > DstTySize && "Not a value truncation"); + if (isFullSet() || getSetSize().getActiveBits() > DstTySize) return ConstantRange(DstTySize, /*isFullSet=*/true); return ConstantRange(Lower.trunc(DstTySize), Upper.trunc(DstTySize)); From eugeni.stepanov at gmail.com Thu Nov 24 06:46:11 2011 From: eugeni.stepanov at gmail.com (Evgeniy Stepanov) Date: Thu, 24 Nov 2011 16:46:11 +0400 Subject: [llvm-commits] Fix constructor order on ARM/ELF Message-ID: This patch fixes PR11322. Current LLVM executes module constructors in reverse priority order because of a mix-up between .ctors and .init_array semantics. It also does a little bit of refactoring by moving StructorOutputOrder field from MCAsmInfo to MCObjectFileInfo so that it can depend on the ABI. Please review. -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.patch Type: text/x-patch Size: 7032 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20111124/8b0d2d57/attachment.bin From sabre at nondot.org Thu Nov 24 11:36:25 2011 From: sabre at nondot.org (Chris Lattner) Date: Thu, 24 Nov 2011 09:36:25 -0800 Subject: [llvm-commits] Vectors of Pointers and Vector-GEP In-Reply-To: <4ECE60ED.30903@free.fr> References: <6594DDFF12B03D4E89690887C248699402A6973563@hasmsx504.ger.corp.intel.com> <4ECCBE6C.2080503@free.fr> <6594DDFF12B03D4E89690887C248699402A697390F@hasmsx504.ger.corp.intel.com> <6594DDFF12B03D4E89690887C248699402A6973C93@hasmsx504.ger.corp.intel.com> <4ECE60ED.30903@free.fr> Message-ID: On Nov 24, 2011, at 7:21 AM, Duncan Sands wrote: > Hi Nadav, I think Chris should at least give his blessing before you start > changing the IR. I think that this makes perfect sense. In terms of implementation roll-out though, I'd suggest generalizing one piece at a time: first allow vector of pointers (resolving the target data issues) with just load/store/insert/extract/shuffle, then add bitcast/inttoptr/ptrtoint, then GEP. This way we have a working and self consistent compiler all along the way. -Chris > > Ciao, Duncan. > > On 24/11/11 12:56, Rotem, Nadav wrote: >> Ping. >> >> >> -----Original Message----- >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Rotem, Nadav >> Sent: Wednesday, November 23, 2011 22:10 >> To: Duncan Sands; llvm-commits at cs.uiuc.edu; LLVM Developers Mailing List >> Subject: Re: [LLVMdev] [llvm-commits] Vectors of Pointers and Vector-GEP >> >> Duncan, >> >> Thanks for the quick review! Here is a short description (design) of where I am going with this patch: >> >> 1. Motivation: Vectors-of-pointers is the first step in supporting scatter/gather instructions (available in AVX2, for example). I believe that this feature was requested on the mailing list before. As mentioned by Hal Finkel earlier today, this feature is desired by autovectorizers as it simplifies the abstraction. I can also mention the Intel OpenCL Autovectorizer and ISPC as two other vectorizers which would benefit from this type. >> >> 2. The type Vectors-of-pointers is similar to the pointer type, in the sense that it cannot be bit-casted and it has no size. It supports the following conversions: >> a. Bitcast to other vector-of-pointers, as long as the element count is the same. >> b. No other bit-cast operations are allowed. >> 3. The type Vectors-of-pointers can be used by the following instructions: >> a. Insertelement/extractelement/shuffle - just like any other vector >> b. Getelementptr - for address calculations, with the restrictions mentioned below. >> c. Intrinsics - to implement the scatter/gather operations >> d. IntToPtr, PtrToInt - for conversion to vectors of integers [This is not implemented in this patch]. >> 4. The getelementptr instruction can be used to access structs, which may cause a problem for vector-geps when accessing different fields. Currently I limit the use of vector-gep to vectors of pointers with a single index. In the future, I may add support for more indices if users of the vector-gep would request for it. Matt Pharr from ISPC also requested support for vectors of arrays, which are not supported at this point. >> 5. The getelementptr indices must all be vectors, if the pointer operand is a vector of pointers. >> >> Regarding your specific comments, Vectors of pointers are a new type in LLVM, so I believe that any predictable and sensible behavior is acceptable. Much like pointers, 'getBitWidth' should return zero. In my current patch bitcasting of one vector pointer to another vector pointer of the same length is okay, but any other bitcast is invalid. I added an assert to getInteger to prevent calling 'getInteger' on vectors of pointers. I agree that IntToPtr and PtrToInt need to be extended in order to support vectors of pointers and I plan to add this. >> >> Thank you, >> Nadav >> >> >> >> >> >> -----Original Message----- >> From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Duncan Sands >> Sent: Wednesday, November 23, 2011 11:36 >> To: llvm-commits at cs.uiuc.edu >> Subject: Re: [llvm-commits] Vectors of Pointers and Vector-GEP >> >> Hi Nadav, >> >>> Following the discussion in last week's LLVM developers conference I started >>> working on support for vectors-of-pointers. Vectors of pointers are needed for >>> supporting scatter/gather operations and are the first step in the direction of >>> supporting predicated architectures. In the attached patch, I change the LLVM-IR >>> in order to support vectors-of-pointers and added basic support for vector-gep. >>> In following patches I plan to extend the vector-gep support to more indices and >>> add scatter/gather intrinsics. >> >> one of the issues with vectors-of-pointers is then you can no longer say what >> the size of a vector is without target data, since you don't know what the size >> of a pointer is without target data. Methods like VectorType::getBitWidth will >> have to be deleted. Methods like VectorType::getTruncatedElementVectorType, >> VectorType::getExtendedElementVectorType and VectorType::getInteger will need to >> either be removed, or changed to take a target data parameter (which is probably >> a layering violation, so they would need to be moved elsewhere). The PtrToInt >> and IntToPtr operations will need to be enhanced to work on vectors, and a >> bunch of places that bitcast vectors will need to become more careful, in case >> they are trying to bitcast between a vector of pointers and a vector of >> integers. >> >> Ciao, Duncan. >> _______________________________________________ >> llvm-commits mailing list >> llvm-commits at cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits >> --------------------------------------------------------------------- >> Intel Israel (74) Limited >> >> This e-mail and any attachments may contain confidential material for >> the sole use of the intended recipient(s). Any review or distribution >> by others is strictly prohibited. If you are not the intended >> recipient, please contact the sender and delete all copies. >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> --------------------------------------------------------------------- >> Intel Israel (74) Limited >> >> This e-mail and any attachments may contain confidential material for >> the sole use of the intended recipient(s). Any review or distribution >> by others is strictly prohibited. If you are not the intended >> recipient, please contact the sender and delete all copies. >> >> >> _______________________________________________ >> llvm-commits mailing list >> llvm-commits at cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits From dmalyshev at accesssoftek.com Thu Nov 24 14:05:55 2011 From: dmalyshev at accesssoftek.com (Danil Malyshev) Date: Thu, 24 Nov 2011 12:05:55 -0800 Subject: [llvm-commits] MachOObjectFile fix functions References: <6AE1604EE3EC5F4296C096518C6B77EE1805B07349@mail.accesssoftek.com> <6AE1604EE3EC5F4296C096518C6B77EE1805C8FA97@mail.accesssoftek.com> <6AE1604EE3EC5F4296C096518C6B77EE18123D6BC3@mail.accesssoftek.com> Message-ID: <6AE1604EE3EC5F4296C096518C6B77EE1AA49B09EF@mail.accesssoftek.com> ping ________________________________ From: Danil Malyshev Sent: Saturday, November 12, 2011 3:00 AM To: 'Owen Anderson' Cc: 'llvm-commits at cs.uiuc.edu' Subject: RE: [llvm-commits] MachOObjectFile fix functions Hello Owen > I see your reasoning here, but it scares me a little bit to have methods with the same name that do different things. > I think we should either rename them to be obviously different, or pick a consistent meaning for all of them. I have renamed symbol.getOffset() as getFileOffset(). Please find attached the changed patch. Regards, Danil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20111124/af60650b/attachment.html From chandlerc at google.com Thu Nov 24 14:16:04 2011 From: chandlerc at google.com (Chandler Carruth) Date: Thu, 24 Nov 2011 12:16:04 -0800 Subject: [llvm-commits] MachOObjectFile fix functions In-Reply-To: <6AE1604EE3EC5F4296C096518C6B77EE1AA49B09EF@mail.accesssoftek.com> References: <6AE1604EE3EC5F4296C096518C6B77EE1805B07349@mail.accesssoftek.com> <6AE1604EE3EC5F4296C096518C6B77EE1805C8FA97@mail.accesssoftek.com> <6AE1604EE3EC5F4296C096518C6B77EE18123D6BC3@mail.accesssoftek.com> <6AE1604EE3EC5F4296C096518C6B77EE1AA49B09EF@mail.accesssoftek.com> Message-ID: On Thu, Nov 24, 2011 at 12:05 PM, Danil Malyshev wrote: > ping Not that 13 days is a great latency for a review round trip, but folks in the US are mostly on holiday at this point. It'll likely be next week before there are further updates... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20111124/317a7591/attachment.html From nadav.rotem at intel.com Thu Nov 24 14:48:28 2011 From: nadav.rotem at intel.com (Rotem, Nadav) Date: Thu, 24 Nov 2011 22:48:28 +0200 Subject: [llvm-commits] Vectors of Pointers and Vector-GEP In-Reply-To: References: <6594DDFF12B03D4E89690887C248699402A6973563@hasmsx504.ger.corp.intel.com> <4ECCBE6C.2080503@free.fr> <6594DDFF12B03D4E89690887C248699402A697390F@hasmsx504.ger.corp.intel.com> <6594DDFF12B03D4E89690887C248699402A6973C93@hasmsx504.ger.corp.intel.com> <4ECE60ED.30903@free.fr> Message-ID: <6594DDFF12B03D4E89690887C248699402A6973EBE@hasmsx504.ger.corp.intel.com> Hi Chris, Duncan, The attached patch as it all: store, load, alloca, shuffle, insert, extract, bitcast, inttoptr, ptrtoinst, and GEP. This patch is not too big, and most of it is tests and docs. Thanks, Nadav -----Original Message----- From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent: Thursday, November 24, 2011 19:36 To: Duncan Sands Cc: llvm-commits at cs.uiuc.edu Subject: Re: [llvm-commits] Vectors of Pointers and Vector-GEP On Nov 24, 2011, at 7:21 AM, Duncan Sands wrote: > Hi Nadav, I think Chris should at least give his blessing before you start > changing the IR. I think that this makes perfect sense. In terms of implementation roll-out though, I'd suggest generalizing one piece at a time: first allow vector of pointers (resolving the target data issues) with just load/store/insert/extract/shuffle, then add bitcast/inttoptr/ptrtoint, then GEP. This way we have a working and self consistent compiler all along the way. -Chris > > Ciao, Duncan. > > On 24/11/11 12:56, Rotem, Nadav wrote: >> Ping. >> >> >> -----Original Message----- >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Rotem, Nadav >> Sent: Wednesday, November 23, 2011 22:10 >> To: Duncan Sands; llvm-commits at cs.uiuc.edu; LLVM Developers Mailing List >> Subject: Re: [LLVMdev] [llvm-commits] Vectors of Pointers and Vector-GEP >> >> Duncan, >> >> Thanks for the quick review! Here is a short description (design) of where I am going with this patch: >> >> 1. Motivation: Vectors-of-pointers is the first step in supporting scatter/gather instructions (available in AVX2, for example). I believe that this feature was requested on the mailing list before. As mentioned by Hal Finkel earlier today, this feature is desired by autovectorizers as it simplifies the abstraction. I can also mention the Intel OpenCL Autovectorizer and ISPC as two other vectorizers which would benefit from this type. >> >> 2. The type Vectors-of-pointers is similar to the pointer type, in the sense that it cannot be bit-casted and it has no size. It supports the following conversions: >> a. Bitcast to other vector-of-pointers, as long as the element count is the same. >> b. No other bit-cast operations are allowed. >> 3. The type Vectors-of-pointers can be used by the following instructions: >> a. Insertelement/extractelement/shuffle - just like any other vector >> b. Getelementptr - for address calculations, with the restrictions mentioned below. >> c. Intrinsics - to implement the scatter/gather operations >> d. IntToPtr, PtrToInt - for conversion to vectors of integers [This is not implemented in this patch]. >> 4. The getelementptr instruction can be used to access structs, which may cause a problem for vector-geps when accessing different fields. Currently I limit the use of vector-gep to vectors of pointers with a single index. In the future, I may add support for more indices if users of the vector-gep would request for it. Matt Pharr from ISPC also requested support for vectors of arrays, which are not supported at this point. >> 5. The getelementptr indices must all be vectors, if the pointer operand is a vector of pointers. >> >> Regarding your specific comments, Vectors of pointers are a new type in LLVM, so I believe that any predictable and sensible behavior is acceptable. Much like pointers, 'getBitWidth' should return zero. In my current patch bitcasting of one vector pointer to another vector pointer of the same length is okay, but any other bitcast is invalid. I added an assert to getInteger to prevent calling 'getInteger' on vectors of pointers. I agree that IntToPtr and PtrToInt need to be extended in order to support vectors of pointers and I plan to add this. >> >> Thank you, >> Nadav >> >> >> >> >> >> -----Original Message----- >> From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Duncan Sands >> Sent: Wednesday, November 23, 2011 11:36 >> To: llvm-commits at cs.uiuc.edu >> Subject: Re: [llvm-commits] Vectors of Pointers and Vector-GEP >> >> Hi Nadav, >> >>> Following the discussion in last week's LLVM developers conference I started >>> working on support for vectors-of-pointers. Vectors of pointers are needed for >>> supporting scatter/gather operations and are the first step in the direction of >>> supporting predicated architectures. In the attached patch, I change the LLVM-IR >>> in order to support vectors-of-pointers and added basic support for vector-gep. >>> In following patches I plan to extend the vector-gep support to more indices and >>> add scatter/gather intrinsics. >> >> one of the issues with vectors-of-pointers is then you can no longer say what >> the size of a vector is without target data, since you don't know what the size >> of a pointer is without target data. Methods like VectorType::getBitWidth will >> have to be deleted. Methods like VectorType::getTruncatedElementVectorType, >> VectorType::getExtendedElementVectorType and VectorType::getInteger will need to >> either be removed, or changed to take a target data parameter (which is probably >> a layering violation, so they would need to be moved elsewhere). The PtrToInt >> and IntToPtr operations will need to be enhanced to work on vectors, and a >> bunch of places that bitcast vectors will need to become more careful, in case >> they are trying to bitcast between a vector of pointers and a vector of >> integers. >> >> Ciao, Duncan. >> _______________________________________________ >> llvm-commits mailing list >> llvm-commits at cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits >> --------------------------------------------------------------------- >> Intel Israel (74) Limited >> >> This e-mail and any attachments may contain confidential material for >> the sole use of the intended recipient(s). Any review or distribution >> by others is strictly prohibited. If you are not the intended >> recipient, please contact the sender and delete all copies. >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> --------------------------------------------------------------------- >> Intel Israel (74) Limited >> >> This e-mail and any attachments may contain confidential material for >> the sole use of the intended recipient(s). Any review or distribution >> by others is strictly prohibited. If you are not the intended >> recipient, please contact the sender and delete all copies. >> >> >> _______________________________________________ >> llvm-commits mailing list >> llvm-commits at cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits _______________________________________________ llvm-commits mailing list llvm-commits at cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -------------- next part -------------- A non-text attachment was scrubbed... Name: vector_gep.patch Type: application/octet-stream Size: 21609 bytes Desc: vector_gep.patch Url : http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20111124/8ace6bfb/attachment.obj From benny.kra at googlemail.com Thu Nov 24 15:14:11 2011 From: benny.kra at googlemail.com (Benjamin Kramer) Date: Thu, 24 Nov 2011 21:14:11 -0000 Subject: [llvm-commits] [llvm] r145124 - in /llvm/trunk: include/llvm/Pass.h lib/VMCore/Pass.cpp Message-ID: <20111124211411.523F22A6C12D@llvm.org> Author: d0k Date: Thu Nov 24 15:14:11 2011 New Revision: 145124 URL: http://llvm.org/viewvc/llvm-project?rev=145124&view=rev Log: Devirtualize Pass::getPassID, overriding it isn't useful and it gets called a lot. While at it pull the trivial ctor in line. Modified: llvm/trunk/include/llvm/Pass.h llvm/trunk/lib/VMCore/Pass.cpp Modified: llvm/trunk/include/llvm/Pass.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Pass.h?rev=145124&r1=145123&r2=145124&view=diff ============================================================================== --- llvm/trunk/include/llvm/Pass.h (original) +++ llvm/trunk/include/llvm/Pass.h Thu Nov 24 15:14:11 2011 @@ -86,7 +86,7 @@ Pass(const Pass &); // DO NOT IMPLEMENT public: - explicit Pass(PassKind K, char &pid); + explicit Pass(PassKind K, char &pid) : Resolver(0), PassID(&pid), Kind(K) { } virtual ~Pass(); @@ -99,7 +99,7 @@ virtual const char *getPassName() const; /// getPassID - Return the PassID number that corresponds to this pass. - virtual AnalysisID getPassID() const { + AnalysisID getPassID() const { return PassID; } Modified: llvm/trunk/lib/VMCore/Pass.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/VMCore/Pass.cpp?rev=145124&r1=145123&r2=145124&view=diff ============================================================================== --- llvm/trunk/lib/VMCore/Pass.cpp (original) +++ llvm/trunk/lib/VMCore/Pass.cpp Thu Nov 24 15:14:11 2011 @@ -25,8 +25,6 @@ // Pass Implementation // -Pass::Pass(PassKind K, char &pid) : Resolver(0), PassID(&pid), Kind(K) { } - // Force out-of-line virtual method. Pass::~Pass() { delete Resolver; From craig.topper at gmail.com Thu Nov 24 16:20:08 2011 From: craig.topper at gmail.com (Craig Topper) Date: Thu, 24 Nov 2011 22:20:08 -0000 Subject: [llvm-commits] [llvm] r145125 - in /llvm/trunk/lib/Target/X86: X86ISelLowering.cpp X86ISelLowering.h X86InstrFragmentsSIMD.td X86InstrSSE.td Message-ID: <20111124222008.B14AF2A6C12D@llvm.org> Author: ctopper Date: Thu Nov 24 16:20:08 2011 New Revision: 145125 URL: http://llvm.org/viewvc/llvm-project?rev=145125&view=rev Log: Remove AVX2 specific X86ISD node types for PUNPCKH/L and instead just reuse the 128-bit versions and let the vector type distinguish. Modified: llvm/trunk/lib/Target/X86/X86ISelLowering.cpp llvm/trunk/lib/Target/X86/X86ISelLowering.h llvm/trunk/lib/Target/X86/X86InstrFragmentsSIMD.td llvm/trunk/lib/Target/X86/X86InstrSSE.td Modified: llvm/trunk/lib/Target/X86/X86ISelLowering.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86ISelLowering.cpp?rev=145125&r1=145124&r2=145125&view=diff ============================================================================== --- llvm/trunk/lib/Target/X86/X86ISelLowering.cpp (original) +++ llvm/trunk/lib/Target/X86/X86ISelLowering.cpp Thu Nov 24 16:20:08 2011 @@ -2851,10 +2851,6 @@ case X86ISD::PUNPCKLBW: case X86ISD::PUNPCKLDQ: case X86ISD::PUNPCKLQDQ: - case X86ISD::VPUNPCKLWDY: - case X86ISD::VPUNPCKLBWY: - case X86ISD::VPUNPCKLDQY: - case X86ISD::VPUNPCKLQDQY: case X86ISD::UNPCKHPS: case X86ISD::UNPCKHPD: case X86ISD::VUNPCKHPSY: @@ -2863,10 +2859,6 @@ case X86ISD::PUNPCKHBW: case X86ISD::PUNPCKHDQ: case X86ISD::PUNPCKHQDQ: - case X86ISD::VPUNPCKHWDY: - case X86ISD::VPUNPCKHBWY: - case X86ISD::VPUNPCKHDQY: - case X86ISD::VPUNPCKHQDQY: case X86ISD::VPERMILPS: case X86ISD::VPERMILPSY: case X86ISD::VPERMILPD: @@ -2940,10 +2932,6 @@ case X86ISD::PUNPCKLBW: case X86ISD::PUNPCKLDQ: case X86ISD::PUNPCKLQDQ: - case X86ISD::VPUNPCKLWDY: - case X86ISD::VPUNPCKLBWY: - case X86ISD::VPUNPCKLDQY: - case X86ISD::VPUNPCKLQDQY: case X86ISD::UNPCKHPS: case X86ISD::UNPCKHPD: case X86ISD::VUNPCKHPSY: @@ -2952,10 +2940,6 @@ case X86ISD::PUNPCKHBW: case X86ISD::PUNPCKHDQ: case X86ISD::PUNPCKHQDQ: - case X86ISD::VPUNPCKHWDY: - case X86ISD::VPUNPCKHBWY: - case X86ISD::VPUNPCKHDQY: - case X86ISD::VPUNPCKHQDQY: return DAG.getNode(Opc, dl, VT, V1, V2); } return SDValue(); @@ -4663,10 +4647,6 @@ case X86ISD::PUNPCKHWD: case X86ISD::PUNPCKHDQ: case X86ISD::PUNPCKHQDQ: - case X86ISD::VPUNPCKHBWY: - case X86ISD::VPUNPCKHWDY: - case X86ISD::VPUNPCKHDQY: - case X86ISD::VPUNPCKHQDQY: DecodePUNPCKHMask(NumElems, ShuffleMask); break; case X86ISD::UNPCKHPS: @@ -4679,10 +4659,6 @@ case X86ISD::PUNPCKLWD: case X86ISD::PUNPCKLDQ: case X86ISD::PUNPCKLQDQ: - case X86ISD::VPUNPCKLBWY: - case X86ISD::VPUNPCKLWDY: - case X86ISD::VPUNPCKLDQY: - case X86ISD::VPUNPCKLQDQY: DecodePUNPCKLMask(VT, ShuffleMask); break; case X86ISD::UNPCKLPS: @@ -6609,17 +6585,17 @@ case MVT::v4f32: return X86ISD::UNPCKLPS; case MVT::v2f64: return X86ISD::UNPCKLPD; case MVT::v8i32: - if (HasAVX2) return X86ISD::VPUNPCKLDQY; + if (HasAVX2) return X86ISD::PUNPCKLDQ; // else use fp unit for int unpack. case MVT::v8f32: return X86ISD::VUNPCKLPSY; case MVT::v4i64: - if (HasAVX2) return X86ISD::VPUNPCKLQDQY; + if (HasAVX2) return X86ISD::PUNPCKLQDQ; // else use fp unit for int unpack. case MVT::v4f64: return X86ISD::VUNPCKLPDY; + case MVT::v32i8: case MVT::v16i8: return X86ISD::PUNPCKLBW; + case MVT::v16i16: case MVT::v8i16: return X86ISD::PUNPCKLWD; - case MVT::v16i16: return X86ISD::VPUNPCKLWDY; - case MVT::v32i8: return X86ISD::VPUNPCKLBWY; default: llvm_unreachable("Unknown type for unpckl"); } @@ -6633,17 +6609,17 @@ case MVT::v4f32: return X86ISD::UNPCKHPS; case MVT::v2f64: return X86ISD::UNPCKHPD; case MVT::v8i32: - if (HasAVX2) return X86ISD::VPUNPCKHDQY; + if (HasAVX2) return X86ISD::PUNPCKHDQ; // else use fp unit for int unpack. case MVT::v8f32: return X86ISD::VUNPCKHPSY; case MVT::v4i64: - if (HasAVX2) return X86ISD::VPUNPCKHQDQY; + if (HasAVX2) return X86ISD::PUNPCKHQDQ; // else use fp unit for int unpack. case MVT::v4f64: return X86ISD::VUNPCKHPDY; + case MVT::v32i8: case MVT::v16i8: return X86ISD::PUNPCKHBW; + case MVT::v16i16: case MVT::v8i16: return X86ISD::PUNPCKHWD; - case MVT::v16i16: return X86ISD::VPUNPCKHWDY; - case MVT::v32i8: return X86ISD::VPUNPCKHBWY; default: llvm_unreachable("Unknown type for unpckh"); } @@ -11312,18 +11288,10 @@ case X86ISD::PUNPCKLWD: return "X86ISD::PUNPCKLWD"; case X86ISD::PUNPCKLDQ: return "X86ISD::PUNPCKLDQ"; case X86ISD::PUNPCKLQDQ: return "X86ISD::PUNPCKLQDQ"; - case X86ISD::VPUNPCKLBWY: return "X86ISD::VPUNPCKLBWY"; - case X86ISD::VPUNPCKLWDY: return "X86ISD::VPUNPCKLWDY"; - case X86ISD::VPUNPCKLDQY: return "X86ISD::VPUNPCKLDQY"; - case X86ISD::VPUNPCKLQDQY: return "X86ISD::VPUNPCKLQDQY"; case X86ISD::PUNPCKHBW: return "X86ISD::PUNPCKHBW"; case X86ISD::PUNPCKHWD: return "X86ISD::PUNPCKHWD"; case X86ISD::PUNPCKHDQ: return "X86ISD::PUNPCKHDQ"; case X86ISD::PUNPCKHQDQ: return "X86ISD::PUNPCKHQDQ"; - case X86ISD::VPUNPCKHBWY: return "X86ISD::VPUNPCKHBWY"; - case X86ISD::VPUNPCKHWDY: return "X86ISD::VPUNPCKHWDY"; - case X86ISD::VPUNPCKHDQY: return "X86ISD::VPUNPCKHDQY"; - case X86ISD::VPUNPCKHQDQY: return "X86ISD::VPUNPCKHQDQY"; case X86ISD::VBROADCAST: return "X86ISD::VBROADCAST"; case X86ISD::VPERMILPS: return "X86ISD::VPERMILPS"; case X86ISD::VPERMILPSY: return "X86ISD::VPERMILPSY"; @@ -14907,10 +14875,6 @@ case X86ISD::PUNPCKHWD: case X86ISD::PUNPCKHDQ: case X86ISD::PUNPCKHQDQ: - case X86ISD::VPUNPCKHBWY: - case X86ISD::VPUNPCKHWDY: - case X86ISD::VPUNPCKHDQY: - case X86ISD::VPUNPCKHQDQY: case X86ISD::UNPCKHPS: case X86ISD::UNPCKHPD: case X86ISD::VUNPCKHPSY: @@ -14919,10 +14883,6 @@ case X86ISD::PUNPCKLWD: case X86ISD::PUNPCKLDQ: case X86ISD::PUNPCKLQDQ: - case X86ISD::VPUNPCKLBWY: - case X86ISD::VPUNPCKLWDY: - case X86ISD::VPUNPCKLDQY: - case X86ISD::VPUNPCKLQDQY: case X86ISD::UNPCKLPS: case X86ISD::UNPCKLPD: case X86ISD::VUNPCKLPSY: Modified: llvm/trunk/lib/Target/X86/X86ISelLowering.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86ISelLowering.h?rev=145125&r1=145124&r2=145125&view=diff ============================================================================== --- llvm/trunk/lib/Target/X86/X86ISelLowering.h (original) +++ llvm/trunk/lib/Target/X86/X86ISelLowering.h Thu Nov 24 16:20:08 2011 @@ -285,18 +285,10 @@ PUNPCKLWD, PUNPCKLDQ, PUNPCKLQDQ, - VPUNPCKLBWY, - VPUNPCKLWDY, - VPUNPCKLDQY, - VPUNPCKLQDQY, PUNPCKHBW, PUNPCKHWD, PUNPCKHDQ, PUNPCKHQDQ, - VPUNPCKHBWY, - VPUNPCKHWDY, - VPUNPCKHDQY, - VPUNPCKHQDQY, VPERMILPS, VPERMILPSY, VPERMILPD, Modified: llvm/trunk/lib/Target/X86/X86InstrFragmentsSIMD.td URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86InstrFragmentsSIMD.td?rev=145125&r1=145124&r2=145125&view=diff ============================================================================== --- llvm/trunk/lib/Target/X86/X86InstrFragmentsSIMD.td (original) +++ llvm/trunk/lib/Target/X86/X86InstrFragmentsSIMD.td Thu Nov 24 16:20:08 2011 @@ -144,19 +144,11 @@ def X86Punpcklwd : SDNode<"X86ISD::PUNPCKLWD", SDTShuff2Op>; def X86Punpckldq : SDNode<"X86ISD::PUNPCKLDQ", SDTShuff2Op>; def X86Punpcklqdq : SDNode<"X86ISD::PUNPCKLQDQ", SDTShuff2Op>; -def X86Punpcklbwy : SDNode<"X86ISD::VPUNPCKLBWY", SDTShuff2Op>; -def X86Punpcklwdy : SDNode<"X86ISD::VPUNPCKLWDY", SDTShuff2Op>; -def X86Punpckldqy : SDNode<"X86ISD::VPUNPCKLDQY", SDTShuff2Op>; -def X86Punpcklqdqy : SDNode<"X86ISD::VPUNPCKLQDQY", SDTShuff2Op>; def X86Punpckhbw : SDNode<"X86ISD::PUNPCKHBW", SDTShuff2Op>; def X86Punpckhwd : SDNode<"X86ISD::PUNPCKHWD", SDTShuff2Op>; def X86Punpckhdq : SDNode<"X86ISD::PUNPCKHDQ", SDTShuff2Op>; def X86Punpckhqdq : SDNode<"X86ISD::PUNPCKHQDQ", SDTShuff2Op>; -def X86Punpckhbwy : SDNode<"X86ISD::VPUNPCKHBWY", SDTShuff2Op>; -def X86Punpckhwdy : SDNode<"X86ISD::VPUNPCKHWDY", SDTShuff2Op>; -def X86Punpckhdqy : SDNode<"X86ISD::VPUNPCKHDQY", SDTShuff2Op>; -def X86Punpckhqdqy : SDNode<"X86ISD::VPUNPCKHQDQY", SDTShuff2Op>; def X86VPermilps : SDNode<"X86ISD::VPERMILPS", SDTShuff2OpI>; def X86VPermilpsy : SDNode<"X86ISD::VPERMILPSY", SDTShuff2OpI>; Modified: llvm/trunk/lib/Target/X86/X86InstrSSE.td URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86InstrSSE.td?rev=145125&r1=145124&r2=145125&view=diff ============================================================================== --- llvm/trunk/lib/Target/X86/X86InstrSSE.td (original) +++ llvm/trunk/lib/Target/X86/X86InstrSSE.td Thu Nov 24 16:20:08 2011 @@ -4218,35 +4218,43 @@ } let Predicates = [HasAVX2] in { - defm VPUNPCKLBW : sse2_unpack_y<0x60, "vpunpcklbw", v32i8, X86Punpcklbwy, + defm VPUNPCKLBW : sse2_unpack_y<0x60, "vpunpcklbw", v32i8, X86Punpcklbw, bc_v32i8>, VEX_4V; - defm VPUNPCKLWD : sse2_unpack_y<0x61, "vpunpcklwd", v16i16, X86Punpcklwdy, + defm VPUNPCKLWD : sse2_unpack_y<0x61, "vpunpcklwd", v16i16, X86Punpcklwd, bc_v16i16>, VEX_4V; - defm VPUNPCKLDQ : sse2_unpack_y<0x62, "vpunpckldq", v8i32, X86Punpckldqy, + defm VPUNPCKLDQ : sse2_unpack_y<0x62, "vpunpckldq", v8i32, X86Punpckldq, bc_v8i32>, VEX_4V; - defm VPUNPCKLQDQ : sse2_unpack_y<0x6C, "vpunpcklqdq", v4i64, X86Punpcklqdqy, + defm VPUNPCKLQDQ : sse2_unpack_y<0x6C, "vpunpcklqdq", v4i64, X86Punpcklqdq, bc_v4i64>, VEX_4V; - defm VPUNPCKHBW : sse2_unpack_y<0x68, "vpunpckhbw", v32i8, X86Punpckhbwy, + defm VPUNPCKHBW : sse2_unpack_y<0x68, "vpunpckhbw", v32i8, X86Punpckhbw, bc_v32i8>, VEX_4V; - defm VPUNPCKHWD : sse2_unpack_y<0x69, "vpunpckhwd", v16i16, X86Punpckhwdy, + defm VPUNPCKHWD : sse2_unpack_y<0x69, "vpunpckhwd", v16i16, X86Punpckhwd, bc_v16i16>, VEX_4V; - defm VPUNPCKHDQ : sse2_unpack_y<0x6A, "vpunpckhdq", v8i32, X86Punpckhdqy, + defm VPUNPCKHDQ : sse2_unpack_y<0x6A, "vpunpckhdq", v8i32, X86Punpckhdq, bc_v8i32>, VEX_4V; - defm VPUNPCKHQDQ : sse2_unpack_y<0x6D, "vpunpckhqdq", v4i64, X86Punpckhqdqy, + defm VPUNPCKHQDQ : sse2_unpack_y<0x6D, "vpunpckhqdq", v4i64, X86Punpckhqdq, bc_v4i64>, VEX_4V; } let Constraints = "$src1 = $dst" in { - defm PUNPCKLBW : sse2_unpack<0x60, "punpcklbw", v16i8, X86Punpcklbw, bc_v16i8>; - defm PUNPCKLWD : sse2_unpack<0x61, "punpcklwd", v8i16, X86Punpcklwd, bc_v8i16>; - defm PUNPCKLDQ : sse2_unpack<0x62, "punpckldq", v4i32, X86Punpckldq, bc_v4i32>; - defm PUNPCKLQDQ : sse2_unpack<0x6C, "punpcklqdq", v2i64, X86Punpcklqdq, bc_v2i64>; - - defm PUNPCKHBW : sse2_unpack<0x68, "punpckhbw", v16i8, X86Punpckhbw, bc_v16i8>; - defm PUNPCKHWD : sse2_unpack<0x69, "punpckhwd", v8i16, X86Punpckhwd, bc_v8i16>; - defm PUNPCKHDQ : sse2_unpack<0x6A, "punpckhdq", v4i32, X86Punpckhdq, bc_v4i32>; - defm PUNPCKHQDQ : sse2_unpack<0x6D, "punpckhqdq", v2i64, X86Punpckhqdq, bc_v2i64>; + defm PUNPCKLBW : sse2_unpack<0x60, "punpcklbw", v16i8, X86Punpcklbw, + bc_v16i8>; + defm PUNPCKLWD : sse2_unpack<0x61, "punpcklwd", v8i16, X86Punpcklwd, + bc_v8i16>; + defm PUNPCKLDQ : sse2_unpack<0x62, "punpckldq", v4i32, X86Punpckldq, + bc_v4i32>; + defm PUNPCKLQDQ : sse2_unpack<0x6C, "punpcklqdq", v2i64, X86Punpcklqdq, + bc_v2i64>; + + defm PUNPCKHBW : sse2_unpack<0x68, "punpckhbw", v16i8, X86Punpckhbw, + bc_v16i8>; + defm PUNPCKHWD : sse2_unpack<0x69, "punpckhwd", v8i16, X86Punpckhwd, + bc_v8i16>; + defm PUNPCKHDQ : sse2_unpack<0x6A, "punpckhdq", v4i32, X86Punpckhdq, + bc_v4i32>; + defm PUNPCKHQDQ : sse2_unpack<0x6D, "punpckhqdq", v2i64, X86Punpckhqdq, + bc_v2i64>; } } // ExeDomain = SSEPackedInt From craig.topper at gmail.com Thu Nov 24 16:57:10 2011 From: craig.topper at gmail.com (Craig Topper) Date: Thu, 24 Nov 2011 22:57:10 -0000 Subject: [llvm-commits] [llvm] r145126 - in /llvm/trunk: lib/Target/X86/X86ISelLowering.cpp lib/Target/X86/X86ISelLowering.h lib/Target/X86/X86InstrFragmentsSIMD.td lib/Target/X86/X86InstrSSE.td test/CodeGen/X86/avx-unpack.ll Message-ID: <20111124225710.833F32A6C12D@llvm.org> Author: ctopper Date: Thu Nov 24 16:57:10 2011 New Revision: 145126 URL: http://llvm.org/viewvc/llvm-project?rev=145126&view=rev Log: Remove 256-bit specific node types for UNPCKHPS/D and instead use the 128-bit versions and let the operand type disinquish. Also fix the load form of the v8i32 patterns for these to realize that the load would be promoted to v4i64. Modified: llvm/trunk/lib/Target/X86/X86ISelLowering.cpp llvm/trunk/lib/Target/X86/X86ISelLowering.h llvm/trunk/lib/Target/X86/X86InstrFragmentsSIMD.td llvm/trunk/lib/Target/X86/X86InstrSSE.td llvm/trunk/test/CodeGen/X86/avx-unpack.ll Modified: llvm/trunk/lib/Target/X86/X86ISelLowering.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86ISelLowering.cpp?rev=145126&r1=145125&r2=145126&view=diff ============================================================================== --- llvm/trunk/lib/Target/X86/X86ISelLowering.cpp (original) +++ llvm/trunk/lib/Target/X86/X86ISelLowering.cpp Thu Nov 24 16:57:10 2011 @@ -2845,16 +2845,12 @@ case X86ISD::MOVSD: case X86ISD::UNPCKLPS: case X86ISD::UNPCKLPD: - case X86ISD::VUNPCKLPSY: - case X86ISD::VUNPCKLPDY: case X86ISD::PUNPCKLWD: case X86ISD::PUNPCKLBW: case X86ISD::PUNPCKLDQ: case X86ISD::PUNPCKLQDQ: case X86ISD::UNPCKHPS: case X86ISD::UNPCKHPD: - case X86ISD::VUNPCKHPSY: - case X86ISD::VUNPCKHPDY: case X86ISD::PUNPCKHWD: case X86ISD::PUNPCKHBW: case X86ISD::PUNPCKHDQ: @@ -2926,16 +2922,12 @@ case X86ISD::MOVSD: case X86ISD::UNPCKLPS: case X86ISD::UNPCKLPD: - case X86ISD::VUNPCKLPSY: - case X86ISD::VUNPCKLPDY: case X86ISD::PUNPCKLWD: case X86ISD::PUNPCKLBW: case X86ISD::PUNPCKLDQ: case X86ISD::PUNPCKLQDQ: case X86ISD::UNPCKHPS: case X86ISD::UNPCKHPD: - case X86ISD::VUNPCKHPSY: - case X86ISD::VUNPCKHPDY: case X86ISD::PUNPCKHWD: case X86ISD::PUNPCKHBW: case X86ISD::PUNPCKHDQ: @@ -4651,8 +4643,6 @@ break; case X86ISD::UNPCKHPS: case X86ISD::UNPCKHPD: - case X86ISD::VUNPCKHPSY: - case X86ISD::VUNPCKHPDY: DecodeUNPCKHPMask(VT, ShuffleMask); break; case X86ISD::PUNPCKLBW: @@ -4663,8 +4653,6 @@ break; case X86ISD::UNPCKLPS: case X86ISD::UNPCKLPD: - case X86ISD::VUNPCKLPSY: - case X86ISD::VUNPCKLPDY: DecodeUNPCKLPMask(VT, ShuffleMask); break; case X86ISD::MOVHLPS: @@ -6582,16 +6570,16 @@ switch(VT.getSimpleVT().SimpleTy) { case MVT::v4i32: return X86ISD::PUNPCKLDQ; case MVT::v2i64: return X86ISD::PUNPCKLQDQ; - case MVT::v4f32: return X86ISD::UNPCKLPS; - case MVT::v2f64: return X86ISD::UNPCKLPD; case MVT::v8i32: if (HasAVX2) return X86ISD::PUNPCKLDQ; // else use fp unit for int unpack. - case MVT::v8f32: return X86ISD::VUNPCKLPSY; + case MVT::v8f32: + case MVT::v4f32: return X86ISD::UNPCKLPS; case MVT::v4i64: if (HasAVX2) return X86ISD::PUNPCKLQDQ; // else use fp unit for int unpack. - case MVT::v4f64: return X86ISD::VUNPCKLPDY; + case MVT::v4f64: + case MVT::v2f64: return X86ISD::UNPCKLPD; case MVT::v32i8: case MVT::v16i8: return X86ISD::PUNPCKLBW; case MVT::v16i16: @@ -6606,16 +6594,16 @@ switch(VT.getSimpleVT().SimpleTy) { case MVT::v4i32: return X86ISD::PUNPCKHDQ; case MVT::v2i64: return X86ISD::PUNPCKHQDQ; - case MVT::v4f32: return X86ISD::UNPCKHPS; - case MVT::v2f64: return X86ISD::UNPCKHPD; case MVT::v8i32: if (HasAVX2) return X86ISD::PUNPCKHDQ; // else use fp unit for int unpack. - case MVT::v8f32: return X86ISD::VUNPCKHPSY; + case MVT::v8f32: + case MVT::v4f32: return X86ISD::UNPCKHPS; case MVT::v4i64: if (HasAVX2) return X86ISD::PUNPCKHQDQ; // else use fp unit for int unpack. - case MVT::v4f64: return X86ISD::VUNPCKHPDY; + case MVT::v4f64: + case MVT::v2f64: return X86ISD::UNPCKHPD; case MVT::v32i8: case MVT::v16i8: return X86ISD::PUNPCKHBW; case MVT::v16i16: @@ -11280,8 +11268,6 @@ case X86ISD::MOVSS: return "X86ISD::MOVSS"; case X86ISD::UNPCKLPS: return "X86ISD::UNPCKLPS"; case X86ISD::UNPCKLPD: return "X86ISD::UNPCKLPD"; - case X86ISD::VUNPCKLPSY: return "X86ISD::VUNPCKLPSY"; - case X86ISD::VUNPCKLPDY: return "X86ISD::VUNPCKLPDY"; case X86ISD::UNPCKHPS: return "X86ISD::UNPCKHPS"; case X86ISD::UNPCKHPD: return "X86ISD::UNPCKHPD"; case X86ISD::PUNPCKLBW: return "X86ISD::PUNPCKLBW"; @@ -14877,16 +14863,12 @@ case X86ISD::PUNPCKHQDQ: case X86ISD::UNPCKHPS: case X86ISD::UNPCKHPD: - case X86ISD::VUNPCKHPSY: - case X86ISD::VUNPCKHPDY: case X86ISD::PUNPCKLBW: case X86ISD::PUNPCKLWD: case X86ISD::PUNPCKLDQ: case X86ISD::PUNPCKLQDQ: case X86ISD::UNPCKLPS: case X86ISD::UNPCKLPD: - case X86ISD::VUNPCKLPSY: - case X86ISD::VUNPCKLPDY: case X86ISD::MOVHLPS: case X86ISD::MOVLHPS: case X86ISD::PSHUFD: Modified: llvm/trunk/lib/Target/X86/X86ISelLowering.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86ISelLowering.h?rev=145126&r1=145125&r2=145126&view=diff ============================================================================== --- llvm/trunk/lib/Target/X86/X86ISelLowering.h (original) +++ llvm/trunk/lib/Target/X86/X86ISelLowering.h Thu Nov 24 16:57:10 2011 @@ -275,12 +275,8 @@ MOVSS, UNPCKLPS, UNPCKLPD, - VUNPCKLPSY, - VUNPCKLPDY, UNPCKHPS, UNPCKHPD, - VUNPCKHPSY, - VUNPCKHPDY, PUNPCKLBW, PUNPCKLWD, PUNPCKLDQ, Modified: llvm/trunk/lib/Target/X86/X86InstrFragmentsSIMD.td URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86InstrFragmentsSIMD.td?rev=145126&r1=145125&r2=145126&view=diff ============================================================================== --- llvm/trunk/lib/Target/X86/X86InstrFragmentsSIMD.td (original) +++ llvm/trunk/lib/Target/X86/X86InstrFragmentsSIMD.td Thu Nov 24 16:57:10 2011 @@ -132,13 +132,9 @@ def X86Unpcklps : SDNode<"X86ISD::UNPCKLPS", SDTShuff2Op>; def X86Unpcklpd : SDNode<"X86ISD::UNPCKLPD", SDTShuff2Op>; -def X86Unpcklpsy : SDNode<"X86ISD::VUNPCKLPSY", SDTShuff2Op>; -def X86Unpcklpdy : SDNode<"X86ISD::VUNPCKLPDY", SDTShuff2Op>; def X86Unpckhps : SDNode<"X86ISD::UNPCKHPS", SDTShuff2Op>; def X86Unpckhpd : SDNode<"X86ISD::UNPCKHPD", SDTShuff2Op>; -def X86Unpckhpsy : SDNode<"X86ISD::VUNPCKHPSY", SDTShuff2Op>; -def X86Unpckhpdy : SDNode<"X86ISD::VUNPCKHPDY", SDTShuff2Op>; def X86Punpcklbw : SDNode<"X86ISD::PUNPCKLBW", SDTShuff2Op>; def X86Punpcklwd : SDNode<"X86ISD::PUNPCKLWD", SDTShuff2Op>; Modified: llvm/trunk/lib/Target/X86/X86InstrSSE.td URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86InstrSSE.td?rev=145126&r1=145125&r2=145126&view=diff ============================================================================== --- llvm/trunk/lib/Target/X86/X86InstrSSE.td (original) +++ llvm/trunk/lib/Target/X86/X86InstrSSE.td Thu Nov 24 16:57:10 2011 @@ -2472,21 +2472,21 @@ def : Pat<(v4f32 (X86Unpckhps VR128:$src1, VR128:$src2)), (VUNPCKHPSrr VR128:$src1, VR128:$src2)>; - def : Pat<(v8f32 (X86Unpcklpsy VR256:$src1, (memopv8f32 addr:$src2))), + def : Pat<(v8f32 (X86Unpcklps VR256:$src1, (memopv8f32 addr:$src2))), (VUNPCKLPSYrm VR256:$src1, addr:$src2)>; - def : Pat<(v8f32 (X86Unpcklpsy VR256:$src1, VR256:$src2)), + def : Pat<(v8f32 (X86Unpcklps VR256:$src1, VR256:$src2)), (VUNPCKLPSYrr VR256:$src1, VR256:$src2)>; - def : Pat<(v8i32 (X86Unpcklpsy VR256:$src1, VR256:$src2)), + def : Pat<(v8i32 (X86Unpcklps VR256:$src1, VR256:$src2)), (VUNPCKLPSYrr VR256:$src1, VR256:$src2)>; - def : Pat<(v8i32 (X86Unpcklpsy VR256:$src1, (memopv8i32 addr:$src2))), + def : Pat<(v8i32 (X86Unpcklps VR256:$src1, (bc_v8i32 (memopv4i64 addr:$src2)))), (VUNPCKLPSYrm VR256:$src1, addr:$src2)>; - def : Pat<(v8f32 (X86Unpckhpsy VR256:$src1, (memopv8f32 addr:$src2))), + def : Pat<(v8f32 (X86Unpckhps VR256:$src1, (memopv8f32 addr:$src2))), (VUNPCKHPSYrm VR256:$src1, addr:$src2)>; - def : Pat<(v8f32 (X86Unpckhpsy VR256:$src1, VR256:$src2)), + def : Pat<(v8f32 (X86Unpckhps VR256:$src1, VR256:$src2)), (VUNPCKHPSYrr VR256:$src1, VR256:$src2)>; - def : Pat<(v8i32 (X86Unpckhpsy VR256:$src1, (memopv8i32 addr:$src2))), + def : Pat<(v8i32 (X86Unpckhps VR256:$src1, (bc_v8i32 (memopv4i64 addr:$src2)))), (VUNPCKHPSYrm VR256:$src1, addr:$src2)>; - def : Pat<(v8i32 (X86Unpckhpsy VR256:$src1, VR256:$src2)), + def : Pat<(v8i32 (X86Unpckhps VR256:$src1, VR256:$src2)), (VUNPCKHPSYrr VR256:$src1, VR256:$src2)>; def : Pat<(v2f64 (X86Unpcklpd VR128:$src1, (memopv2f64 addr:$src2))), @@ -2498,21 +2498,21 @@ def : Pat<(v2f64 (X86Unpckhpd VR128:$src1, VR128:$src2)), (VUNPCKHPDrr VR128:$src1, VR128:$src2)>; - def : Pat<(v4f64 (X86Unpcklpdy VR256:$src1, (memopv4f64 addr:$src2))), + def : Pat<(v4f64 (X86Unpcklpd VR256:$src1, (memopv4f64 addr:$src2))), (VUNPCKLPDYrm VR256:$src1, addr:$src2)>; - def : Pat<(v4f64 (X86Unpcklpdy VR256:$src1, VR256:$src2)), + def : Pat<(v4f64 (X86Unpcklpd VR256:$src1, VR256:$src2)), (VUNPCKLPDYrr VR256:$src1, VR256:$src2)>; - def : Pat<(v4i64 (X86Unpcklpdy VR256:$src1, (memopv4i64 addr:$src2))), + def : Pat<(v4i64 (X86Unpcklpd VR256:$src1, (memopv4i64 addr:$src2))), (VUNPCKLPDYrm VR256:$src1, addr:$src2)>; - def : Pat<(v4i64 (X86Unpcklpdy VR256:$src1, VR256:$src2)), + def : Pat<(v4i64 (X86Unpcklpd VR256:$src1, VR256:$src2)), (VUNPCKLPDYrr VR256:$src1, VR256:$src2)>; - def : Pat<(v4f64 (X86Unpckhpdy VR256:$src1, (memopv4f64 addr:$src2))), + def : Pat<(v4f64 (X86Unpckhpd VR256:$src1, (memopv4f64 addr:$src2))), (VUNPCKHPDYrm VR256:$src1, addr:$src2)>; - def : Pat<(v4f64 (X86Unpckhpdy VR256:$src1, VR256:$src2)), + def : Pat<(v4f64 (X86Unpckhpd VR256:$src1, VR256:$src2)), (VUNPCKHPDYrr VR256:$src1, VR256:$src2)>; - def : Pat<(v4i64 (X86Unpckhpdy VR256:$src1, (memopv4i64 addr:$src2))), + def : Pat<(v4i64 (X86Unpckhpd VR256:$src1, (memopv4i64 addr:$src2))), (VUNPCKHPDYrm VR256:$src1, addr:$src2)>; - def : Pat<(v4i64 (X86Unpckhpdy VR256:$src1, VR256:$src2)), + def : Pat<(v4i64 (X86Unpckhpd VR256:$src1, VR256:$src2)), (VUNPCKHPDYrr VR256:$src1, VR256:$src2)>; // FIXME: Instead of X86Movddup, there should be a X86Unpcklpd here, the Modified: llvm/trunk/test/CodeGen/X86/avx-unpack.ll URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/avx-unpack.ll?rev=145126&r1=145125&r2=145126&view=diff ============================================================================== --- llvm/trunk/test/CodeGen/X86/avx-unpack.ll (original) +++ llvm/trunk/test/CodeGen/X86/avx-unpack.ll Thu Nov 24 16:57:10 2011 @@ -67,6 +67,15 @@ ret <8 x i32> %shuffle.i } +; CHECK: vunpckhps (% +define <8 x i32> @unpackhips2(<8 x i32>* %src1, <8 x i32>* %src2) nounwind uwtable readnone ssp { +entry: + %a = load <8 x i32>* %src1 + %b = load <8 x i32>* %src2 + %shuffle.i = shufflevector <8 x i32> %a, <8 x i32> %b, <8 x i32> + ret <8 x i32> %shuffle.i +} + ; CHECK: vunpckhpd define <4 x i64> @unpackhipd1(<4 x i64> %src1, <4 x i64> %src2) nounwind uwtable readnone ssp { entry: @@ -74,6 +83,15 @@ ret <4 x i64> %shuffle.i } +; CHECK: vunpckhpd (% +define <4 x i64> @unpackhipd2(<4 x i64>* %src1, <4 x i64>* %src2) nounwind uwtable readnone ssp { +entry: + %a = load <4 x i64>* %src1 + %b = load <4 x i64>* %src2 + %shuffle.i = shufflevector <4 x i64> %a, <4 x i64> %b, <4 x i32> + ret <4 x i64> %shuffle.i +} + ; CHECK: vunpcklps define <8 x i32> @unpacklops1(<8 x i32> %src1, <8 x i32> %src2) nounwind uwtable readnone ssp { entry: @@ -81,9 +99,27 @@ ret <8 x i32> %shuffle.i } +; CHECK: vunpcklps (% +define <8 x i32> @unpacklops2(<8 x i32>* %src1, <8 x i32>* %src2) nounwind uwtable readnone ssp { +entry: + %a = load <8 x i32>* %src1 + %b = load <8 x i32>* %src2 + %shuffle.i = shufflevector <8 x i32> %a, <8 x i32> %b, <8 x i32> + ret <8 x i32> %shuffle.i +} + ; CHECK: vunpcklpd define <4 x i64> @unpacklopd1(<4 x i64> %src1, <4 x i64> %src2) nounwind uwtable readnone ssp { entry: %shuffle.i = shufflevector <4 x i64> %src1, <4 x i64> %src2, <4 x i32> ret <4 x i64> %shuffle.i } + +; CHECK: vunpcklpd (% +define <4 x i64> @unpacklopd2(<4 x i64>* %src1, <4 x i64>* %src2) nounwind uwtable readnone ssp { +entry: + %a = load <4 x i64>* %src1 + %b = load <4 x i64>* %src2 + %shuffle.i = shufflevector <4 x i64> %a, <4 x i64> %b, <4 x i32> + ret <4 x i64> %shuffle.i +} From stpworld at narod.ru Fri Nov 25 01:57:14 2011 From: stpworld at narod.ru (Stepan Dyatkovskiy) Date: Fri, 25 Nov 2011 11:57:14 +0400 Subject: [llvm-commits] [LLVM, loop-unswitch, bugfix for #11429] Wrong behaviour for switches. Message-ID: <4ECF4A5A.9030607@narod.ru> Hi all. Please find the patch in attachment for review. Regression tests are attached in separated patch. Short tests description: 2011-11-18-SimpleSwitch.ll Check simple that simple switch will totally unswitched: for (...) switch(c) { case 0: inc(); break; case 1: dec(); break; default: goto loop_exit; } loop_exit: ... Result of processing should be 2 additional loops for c == 0 and for c == 1. 2011-11-18-TwoSwitches.ll Check that second switch will unswitched too. Check that switches will not unswitched again in new loop: Initially we have the next: for (...) { switch(c) { case 0: inc(); break; } switch(d) { case 0: inc(); break; } } After optimization we should got 3 additional loops: when (c == 0 && d == 0), when (c == 0 && d != 0) and when (c != 0 && d == 0). Original loop will activated for (c != 0 && d != 0): if (c == 0 && d == 0) { for (...) ... // All is clear here. Two "switch(0)" instructions. } else if (c == 0 && d != 0) { for (...) { switch (0) { // c == 0 case 0: inc(); break; } switch (d) { case 0: goto unreachable; // CHECK: That it will not unswitched // again, since it looks "trivial", // see LoopUnswitch::IsTrivialUnswitchCondition } } } else if (c != 0 && d == 0) { // the same... ... } else { // if (c != 0 && d != 0) // Original totally unswitched loop: switch (c) { case 0: goto unreachable; } switch (d) { case 0: goto unreachable; } } Stepan. -------------- next part -------------- A non-text attachment was scrubbed... Name: loop-unswitch-unswitchvals.patch Type: text/x-patch Size: 6510 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20111125/4a6bbad3/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: loop-unswitch-unswitchvals-regtests.patch Type: text/x-patch Size: 9724 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20111125/4a6bbad3/attachment-0003.bin From geek4civic at gmail.com Fri Nov 25 03:19:57 2011 From: geek4civic at gmail.com (NAKAMURA Takumi) Date: Fri, 25 Nov 2011 09:19:57 -0000 Subject: [llvm-commits] [llvm] r145129 - /llvm/trunk/lib/Target/ARM/ARMLoadStoreOptimizer.cpp Message-ID: <20111125091957.48EDE2A6C12D@llvm.org> Author: chapuni Date: Fri Nov 25 03:19:57 2011 New Revision: 145129 URL: http://llvm.org/viewvc/llvm-project?rev=145129&view=rev Log: ARMLoadStoreOptimizer.cpp: Fix MSVC(Debug) build. Modified: llvm/trunk/lib/Target/ARM/ARMLoadStoreOptimizer.cpp Modified: llvm/trunk/lib/Target/ARM/ARMLoadStoreOptimizer.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/ARM/ARMLoadStoreOptimizer.cpp?rev=145129&r1=145128&r2=145129&view=diff ============================================================================== --- llvm/trunk/lib/Target/ARM/ARMLoadStoreOptimizer.cpp (original) +++ llvm/trunk/lib/Target/ARM/ARMLoadStoreOptimizer.cpp Fri Nov 25 03:19:57 2011 @@ -33,6 +33,7 @@ #include "llvm/Target/TargetRegisterInfo.h" #include "llvm/Support/ErrorHandling.h" #include "llvm/Support/Debug.h" +#include "llvm/Support/raw_ostream.h" #include "llvm/ADT/DenseMap.h" #include "llvm/ADT/STLExtras.h" #include "llvm/ADT/SmallPtrSet.h" From baldrick at free.fr Fri Nov 25 07:05:04 2011 From: baldrick at free.fr (Duncan Sands) Date: Fri, 25 Nov 2011 13:05:04 -0000 Subject: [llvm-commits] [dragonegg] r145130 - /dragonegg/trunk/src/Convert.cpp Message-ID: <20111125130504.D2FB32A6C12D@llvm.org> Author: baldrick Date: Fri Nov 25 07:05:04 2011 New Revision: 145130 URL: http://llvm.org/viewvc/llvm-project?rev=145130&view=rev Log: Turn __builtin_expect into a call to LLVM's expect intrinsic. Modified: dragonegg/trunk/src/Convert.cpp Modified: dragonegg/trunk/src/Convert.cpp URL: http://llvm.org/viewvc/llvm-project/dragonegg/trunk/src/Convert.cpp?rev=145130&r1=145129&r2=145130&view=diff ============================================================================== --- dragonegg/trunk/src/Convert.cpp (original) +++ dragonegg/trunk/src/Convert.cpp Fri Nov 25 07:05:04 2011 @@ -5023,11 +5023,18 @@ } bool TreeToLLVM::EmitBuiltinExpect(gimple stmt, Value *&Result) { - // Ignore the hint for now, just expand the expr. This is safe, but not - // optimal. - Result = gimple_call_num_args(stmt) < 2 ? - Constant::getNullValue(ConvertType(gimple_call_return_type(stmt))) : - EmitMemory(gimple_call_arg(stmt, 0)); + tree type = gimple_call_return_type(stmt); + if (gimple_call_num_args(stmt) < 2) { + Result = Constant::getNullValue(ConvertType(type)); + return true; + } + Type *ArgTy = getRegType(type); + Value *ExpectIntr = Intrinsic::getDeclaration(TheModule, Intrinsic::expect, + ArgTy); + Value *ArgValue = EmitRegister(gimple_call_arg(stmt, 0)); + Value *ExpectedValue = EmitRegister(gimple_call_arg(stmt, 1)); + Result = Builder.CreateCall2(ExpectIntr, ArgValue, ExpectedValue); + Result = Reg2Mem(Result, type, Builder); return true; } From nadav.rotem at intel.com Fri Nov 25 07:12:08 2011 From: nadav.rotem at intel.com (Rotem, Nadav) Date: Fri, 25 Nov 2011 15:12:08 +0200 Subject: [llvm-commits] Vectors of Pointers and Vector-GEP In-Reply-To: <6594DDFF12B03D4E89690887C248699402A6973EBE@hasmsx504.ger.corp.intel.com> References: <6594DDFF12B03D4E89690887C248699402A6973563@hasmsx504.ger.corp.intel.com> <4ECCBE6C.2080503@free.fr> <6594DDFF12B03D4E89690887C248699402A697390F@hasmsx504.ger.corp.intel.com> <6594DDFF12B03D4E89690887C248699402A6973C93@hasmsx504.ger.corp.intel.com> <4ECE60ED.30903@free.fr> <6594DDFF12B03D4E89690887C248699402A6973EBE@hasmsx504.ger.corp.intel.com> Message-ID: <6594DDFF12B03D4E89690887C248699402A6973F5B@hasmsx504.ger.corp.intel.com> Ping. -----Original Message----- From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Rotem, Nadav Sent: Thursday, November 24, 2011 22:48 To: Chris Lattner; Duncan Sands Cc: llvm-commits at cs.uiuc.edu Subject: Re: [llvm-commits] Vectors of Pointers and Vector-GEP Hi Chris, Duncan, The attached patch as it all: store, load, alloca, shuffle, insert, extract, bitcast, inttoptr, ptrtoinst, and GEP. This patch is not too big, and most of it is tests and docs. Thanks, Nadav -----Original Message----- From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent: Thursday, November 24, 2011 19:36 To: Duncan Sands Cc: llvm-commits at cs.uiuc.edu Subject: Re: [llvm-commits] Vectors of Pointers and Vector-GEP On Nov 24, 2011, at 7:21 AM, Duncan Sands wrote: > Hi Nadav, I think Chris should at least give his blessing before you > start changing the IR. I think that this makes perfect sense. In terms of implementation roll-out though, I'd suggest generalizing one piece at a time: first allow vector of pointers (resolving the target data issues) with just load/store/insert/extract/shuffle, then add bitcast/inttoptr/ptrtoint, then GEP. This way we have a working and self consistent compiler all along the way. -Chris > > Ciao, Duncan. > > On 24/11/11 12:56, Rotem, Nadav wrote: >> Ping. >> >> >> -----Original Message----- >> From: llvmdev-bounces at cs.uiuc.edu >> [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Rotem, Nadav >> Sent: Wednesday, November 23, 2011 22:10 >> To: Duncan Sands; llvm-commits at cs.uiuc.edu; LLVM Developers Mailing >> List >> Subject: Re: [LLVMdev] [llvm-commits] Vectors of Pointers and >> Vector-GEP >> >> Duncan, >> >> Thanks for the quick review! Here is a short description (design) of where I am going with this patch: >> >> 1. Motivation: Vectors-of-pointers is the first step in supporting scatter/gather instructions (available in AVX2, for example). I believe that this feature was requested on the mailing list before. As mentioned by Hal Finkel earlier today, this feature is desired by autovectorizers as it simplifies the abstraction. I can also mention the Intel OpenCL Autovectorizer and ISPC as two other vectorizers which would benefit from this type. >> >> 2. The type Vectors-of-pointers is similar to the pointer type, in the sense that it cannot be bit-casted and it has no size. It supports the following conversions: >> a. Bitcast to other vector-of-pointers, as long as the element count is the same. >> b. No other bit-cast operations are allowed. >> 3. The type Vectors-of-pointers can be used by the following instructions: >> a. Insertelement/extractelement/shuffle - just like any other vector >> b. Getelementptr - for address calculations, with the restrictions mentioned below. >> c. Intrinsics - to implement the scatter/gather operations >> d. IntToPtr, PtrToInt - for conversion to vectors of integers [This is not implemented in this patch]. >> 4. The getelementptr instruction can be used to access structs, which may cause a problem for vector-geps when accessing different fields. Currently I limit the use of vector-gep to vectors of pointers with a single index. In the future, I may add support for more indices if users of the vector-gep would request for it. Matt Pharr from ISPC also requested support for vectors of arrays, which are not supported at this point. >> 5. The getelementptr indices must all be vectors, if the pointer operand is a vector of pointers. >> >> Regarding your specific comments, Vectors of pointers are a new type in LLVM, so I believe that any predictable and sensible behavior is acceptable. Much like pointers, 'getBitWidth' should return zero. In my current patch bitcasting of one vector pointer to another vector pointer of the same length is okay, but any other bitcast is invalid. I added an assert to getInteger to prevent calling 'getInteger' on vectors of pointers. I agree that IntToPtr and PtrToInt need to be extended in order to support vectors of pointers and I plan to add this. >> >> Thank you, >> Nadav >> >> >> >> >> >> -----Original Message----- >> From: llvm-commits-bounces at cs.uiuc.edu >> [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Duncan Sands >> Sent: Wednesday, November 23, 2011 11:36 >> To: llvm-commits at cs.uiuc.edu >> Subject: Re: [llvm-commits] Vectors of Pointers and Vector-GEP >> >> Hi Nadav, >> >>> Following the discussion in last week's LLVM developers conference I >>> started working on support for vectors-of-pointers. Vectors of >>> pointers are needed for supporting scatter/gather operations and are >>> the first step in the direction of supporting predicated >>> architectures. In the attached patch, I change the LLVM-IR in order to support vectors-of-pointers and added basic support for vector-gep. >>> In following patches I plan to extend the vector-gep support to more >>> indices and add scatter/gather intrinsics. >> >> one of the issues with vectors-of-pointers is then you can no longer >> say what the size of a vector is without target data, since you don't >> know what the size of a pointer is without target data. Methods like >> VectorType::getBitWidth will have to be deleted. Methods like >> VectorType::getTruncatedElementVectorType, >> VectorType::getExtendedElementVectorType and VectorType::getInteger >> will need to either be removed, or changed to take a target data >> parameter (which is probably a layering violation, so they would need >> to be moved elsewhere). The PtrToInt and IntToPtr operations will >> need to be enhanced to work on vectors, and a bunch of places that >> bitcast vectors will need to become more careful, in case they are >> trying to bitcast between a vector of pointers and a vector of integers. >> >> Ciao, Duncan. >> _______________________________________________ >> llvm-commits mailing list >> llvm-commits at cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits >> --------------------------------------------------------------------- >> Intel Israel (74) Limited >> >> This e-mail and any attachments may contain confidential material for >> the sole use of the intended recipient(s). Any review or distribution >> by others is strictly prohibited. If you are not the intended >> recipient, please contact the sender and delete all copies. >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> --------------------------------------------------------------------- >> Intel Israel (74) Limited >> >> This e-mail and any attachments may contain confidential material for >> the sole use of the intended recipient(s). Any review or distribution >> by others is strictly prohibited. If you are not the intended >> recipient, please contact the sender and delete all copies. >> >> >> _______________________________________________ >> llvm-commits mailing list >> llvm-commits at cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits _______________________________________________ llvm-commits mailing list llvm-commits at cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From baldrick at free.fr Fri Nov 25 08:22:25 2011 From: baldrick at free.fr (Duncan Sands) Date: Fri, 25 Nov 2011 14:22:25 -0000 Subject: [llvm-commits] [dragonegg] r145131 - /dragonegg/trunk/src/Backend.cpp Message-ID: <20111125142225.A32C42A6C12D@llvm.org> Author: baldrick Date: Fri Nov 25 08:22:25 2011 New Revision: 145131 URL: http://llvm.org/viewvc/llvm-project?rev=145131&view=rev Log: Don't include ManagedStatic.h because it includes LLVM's configure information which clashes with GCC's (which we can't not include). They both define things the same way, but that doesn't stop GCC from warning about it. Modified: dragonegg/trunk/src/Backend.cpp Modified: dragonegg/trunk/src/Backend.cpp URL: http://llvm.org/viewvc/llvm-project/dragonegg/trunk/src/Backend.cpp?rev=145131&r1=145130&r2=145131&view=diff ============================================================================== --- dragonegg/trunk/src/Backend.cpp (original) +++ dragonegg/trunk/src/Backend.cpp Fri Nov 25 08:22:25 2011 @@ -40,7 +40,6 @@ #include "llvm/Bitcode/ReaderWriter.h" #include "llvm/CodeGen/RegAllocRegistry.h" #include "llvm/MC/SubtargetFeature.h" -#include "llvm/Support/ManagedStatic.h" #include "llvm/Support/TargetRegistry.h" #include "llvm/Target/TargetData.h" #include "llvm/Target/TargetLibraryInfo.h" @@ -82,6 +81,9 @@ #error Unsupported GCC major version #endif +// llvm_shutdown - Declared in llvm/Support/ManagedStatic.h. +extern void llvm_shutdown(); + // Non-zero if libcalls should not be simplified. int flag_no_simplify_libcalls; From baldrick at free.fr Fri Nov 25 10:19:11 2011 From: baldrick at free.fr (Duncan Sands) Date: Fri, 25 Nov 2011 16:19:11 -0000 Subject: [llvm-commits] [dragonegg] r145132 - /dragonegg/trunk/src/Backend.cpp Message-ID: <20111125161912.092DE2A6C12D@llvm.org> Author: baldrick Date: Fri Nov 25 10:19:11 2011 New Revision: 145132 URL: http://llvm.org/viewvc/llvm-project?rev=145132&view=rev Log: Fix unresolved symbol. Modified: dragonegg/trunk/src/Backend.cpp Modified: dragonegg/trunk/src/Backend.cpp URL: http://llvm.org/viewvc/llvm-project/dragonegg/trunk/src/Backend.cpp?rev=145132&r1=145131&r2=145132&view=diff ============================================================================== --- dragonegg/trunk/src/Backend.cpp (original) +++ dragonegg/trunk/src/Backend.cpp Fri Nov 25 10:19:11 2011 @@ -82,7 +82,9 @@ #endif // llvm_shutdown - Declared in llvm/Support/ManagedStatic.h. -extern void llvm_shutdown(); +namespace llvm { + extern void llvm_shutdown(); +} // Non-zero if libcalls should not be simplified. int flag_no_simplify_libcalls; From stpworld at narod.ru Fri Nov 25 13:15:47 2011 From: stpworld at narod.ru (Stepan Dyatkovskiy) Date: Fri, 25 Nov 2011 23:15:47 +0400 Subject: [llvm-commits] [LLVM, loop-unswitch] Potential bug in RewriteLoopBodyWithConditionConstant In-Reply-To: References: <4ECB80FC.3070307@narod.ru> <4ECB8437.9010708@free.fr> <4ECB9786.9070104@narod.ru> <4ECD34CA.50501@narod.ru> <4ECD35C7.4000905@free.fr> Message-ID: <4ECFE963.6030107@narod.ru> Anton Korobeynikov wrote: >> I think Anton commented on your first patch too, but quite differently >> to me. Anton, are you OK with this? > I'm still a bit worried: we're definitely changing the list of users > on-fly. Won't this invalidate the iterators? > They are definitely became invalid. Just look at dumps I attached before. I found that: 1. Next iterator (++UI) stay correct. 2. After replaceUsesOfWith was invoked, current iterator will redirected to Replacement's use-list. But for another method we have risk to got absolutely different behaviour. Considering this version of patch we need to comment this place IMHO. About WorkList. I missed it. Of course we can process this one. From bruno.cardoso at gmail.com Fri Nov 25 13:33:43 2011 From: bruno.cardoso at gmail.com (Bruno Cardoso Lopes) Date: Fri, 25 Nov 2011 19:33:43 -0000 Subject: [llvm-commits] [llvm] r145133 - in /llvm/trunk: include/llvm/IntrinsicsX86.td lib/Target/X86/MCTargetDesc/X86BaseInfo.h lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp lib/Target/X86/X86InstrFMA.td lib/Target/X86/X86InstrFormats.td test/CodeGen/X86/fma4-intrinsics-x86_64.ll test/MC/X86/x86_64-fma4-encoding.s Message-ID: <20111125193343.5F9342A6C12D@llvm.org> Author: bruno Date: Fri Nov 25 13:33:42 2011 New Revision: 145133 URL: http://llvm.org/viewvc/llvm-project?rev=145133&view=rev Log: This patch contains support for encoding FMA4 instructions and tablegen patterns for scalar FMA4 operations and intrinsic. Also add tests for vfmaddsd. Patch by Jan Sjodin Added: llvm/trunk/test/CodeGen/X86/fma4-intrinsics-x86_64.ll llvm/trunk/test/MC/X86/x86_64-fma4-encoding.s Modified: llvm/trunk/include/llvm/IntrinsicsX86.td llvm/trunk/lib/Target/X86/MCTargetDesc/X86BaseInfo.h llvm/trunk/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp llvm/trunk/lib/Target/X86/X86InstrFMA.td llvm/trunk/lib/Target/X86/X86InstrFormats.td Modified: llvm/trunk/include/llvm/IntrinsicsX86.td URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/IntrinsicsX86.td?rev=145133&r1=145132&r2=145133&view=diff ============================================================================== --- llvm/trunk/include/llvm/IntrinsicsX86.td (original) +++ llvm/trunk/include/llvm/IntrinsicsX86.td Fri Nov 25 13:33:42 2011 @@ -1822,6 +1822,16 @@ } //===----------------------------------------------------------------------===// +// FMA4 + +let TargetPrefix = "x86" in { // All intrinsics start with "llvm.x86.". + def int_x86_fma4_vfmadd_sd : GCCBuiltin<"__builtin_ia32_vfmaddsd">, + Intrinsic<[llvm_v2f64_ty], + [llvm_v2f64_ty, llvm_v2f64_ty, llvm_v2f64_ty], + [IntrNoMem]>; +} + +//===----------------------------------------------------------------------===// // MMX // Empty MMX state op. Modified: llvm/trunk/lib/Target/X86/MCTargetDesc/X86BaseInfo.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/MCTargetDesc/X86BaseInfo.h?rev=145133&r1=145132&r2=145133&view=diff ============================================================================== --- llvm/trunk/lib/Target/X86/MCTargetDesc/X86BaseInfo.h (original) +++ llvm/trunk/lib/Target/X86/MCTargetDesc/X86BaseInfo.h Fri Nov 25 13:33:42 2011 @@ -418,7 +418,12 @@ /// storing a classifier in the imm8 field. To simplify our implementation, /// we handle this by storeing the classifier in the opcode field and using /// this flag to indicate that the encoder should do the wacky 3DNow! thing. - Has3DNow0F0FOpcode = 1U << 7 + Has3DNow0F0FOpcode = 1U << 7, + + /// XOP_W - Same bit as VEX_W. Used to indicate swapping of + /// operand 3 and 4 to be encoded in ModRM or I8IMM. This is used + /// for FMA4 and XOP instructions. + XOP_W = 1U << 8 }; // getBaseOpcodeFor - This function returns the "base" X86 opcode for the @@ -488,9 +493,12 @@ return 0; case X86II::MRMSrcMem: { bool HasVEX_4V = (TSFlags >> X86II::VEXShift) & X86II::VEX_4V; + bool HasXOP_W = (TSFlags >> X86II::VEXShift) & X86II::XOP_W; unsigned FirstMemOp = 1; if (HasVEX_4V) ++FirstMemOp;// Skip the register source (which is encoded in VEX_VVVV). + if (HasXOP_W) + ++FirstMemOp;// Skip the register source (which is encoded in I8IMM). // FIXME: Maybe lea should have its own form? This is a horrible hack. //if (Opcode == X86::LEA64r || Opcode == X86::LEA64_32r || Modified: llvm/trunk/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp?rev=145133&r1=145132&r2=145133&view=diff ============================================================================== --- llvm/trunk/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp (original) +++ llvm/trunk/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp Fri Nov 25 13:33:42 2011 @@ -415,6 +415,10 @@ // opcode extension, or ignored, depending on the opcode byte) unsigned char VEX_W = 0; + // XOP_W: opcode specific, same bit as VEX_W, but used to + // swap operand 3 and 4 for FMA4 and XOP instructions + unsigned char XOP_W = 0; + // VEX_5M (VEX m-mmmmm field): // // 0b00000: Reserved for future use @@ -453,6 +457,9 @@ if ((TSFlags >> X86II::VEXShift) & X86II::VEX_W) VEX_W = 1; + if ((TSFlags >> X86II::VEXShift) & X86II::XOP_W) + XOP_W = 1; + if ((TSFlags >> X86II::VEXShift) & X86II::VEX_L) VEX_L = 1; @@ -529,6 +536,9 @@ // src1(ModR/M), MemAddr, imm8 // src1(ModR/M), MemAddr, src2(VEX_I8IMM) // + // FMA4: + // dst(ModR/M.reg), src1(VEX_4V), src2(ModR/M), src3(VEX_I8IMM) + // dst(ModR/M.reg), src1(VEX_4V), src2(VEX_I8IMM), src3(ModR/M), if (X86II::isX86_64ExtendedReg(MI.getOperand(0).getReg())) VEX_R = 0x0; @@ -629,7 +639,7 @@ // 3 byte VEX prefix EmitByte(0xC4, CurByte, OS); EmitByte(VEX_R << 7 | VEX_X << 6 | VEX_B << 5 | VEX_5M, CurByte, OS); - EmitByte(LastByte | (VEX_W << 7), CurByte, OS); + EmitByte(LastByte | ((VEX_W | XOP_W) << 7), CurByte, OS); } /// DetermineREXPrefix - Determine if the MCInst has to be encoded with a X86-64 @@ -889,6 +899,8 @@ // It uses the VEX.VVVV field? bool HasVEX_4V = (TSFlags >> X86II::VEXShift) & X86II::VEX_4V; bool HasVEX_4VOp3 = (TSFlags >> X86II::VEXShift) & X86II::VEX_4VOp3; + bool HasXOP_W = (TSFlags >> X86II::VEXShift) & X86II::XOP_W; + unsigned XOP_W_I8IMMOperand = 2; // Determine where the memory operand starts, if present. int MemoryOperand = X86II::getMemoryOperandNo(TSFlags, Opcode); @@ -961,6 +973,10 @@ if (HasVEX_4V) // Skip 1st src (which is encoded in VEX_VVVV) SrcRegNum++; + // GAS sets the XOP_W even with register operands, we want to match this. + // XOP_W is ignored, so there is no swapping of the operands + XOP_W_I8IMMOperand = 3; + EmitRegModRMByte(MI.getOperand(SrcRegNum), GetX86RegNum(MI.getOperand(CurOp)), CurByte, OS); CurOp = SrcRegNum + 1; @@ -975,14 +991,20 @@ ++AddrOperands; ++FirstMemOp; // Skip the register source (which is encoded in VEX_VVVV). } + if(HasXOP_W) // Skip second register source (encoded in I8IMM) + ++FirstMemOp; EmitByte(BaseOpcode, CurByte, OS); EmitMemModRMByte(MI, FirstMemOp, GetX86RegNum(MI.getOperand(CurOp)), TSFlags, CurByte, OS, Fixups); - CurOp += AddrOperands + 1; - if (HasVEX_4VOp3) - ++CurOp; + if(HasXOP_W) { + CurOp = NumOps - 1; // We have consumed all except one operand (third) + } else { + CurOp += AddrOperands + 1; + if (HasVEX_4VOp3) + ++CurOp; + } break; } @@ -1064,7 +1086,9 @@ // The last source register of a 4 operand instruction in AVX is encoded // in bits[7:4] of a immediate byte, and bits[3:0] are ignored. if ((TSFlags >> X86II::VEXShift) & X86II::VEX_I8IMM) { - const MCOperand &MO = MI.getOperand(CurOp++); + const MCOperand &MO = MI.getOperand(HasXOP_W ? XOP_W_I8IMMOperand + : CurOp); + CurOp++; bool IsExtReg = X86II::isX86_64ExtendedReg(MO.getReg()); unsigned RegNum = (IsExtReg ? (1 << 7) : 0); RegNum |= GetX86RegNum(MO) << 4; Modified: llvm/trunk/lib/Target/X86/X86InstrFMA.td URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86InstrFMA.td?rev=145133&r1=145132&r2=145133&view=diff ============================================================================== --- llvm/trunk/lib/Target/X86/X86InstrFMA.td (original) +++ llvm/trunk/lib/Target/X86/X86InstrFMA.td Fri Nov 25 13:33:42 2011 @@ -58,3 +58,42 @@ defm VFNMSUBPS : fma_forms<0x9E, 0xAE, 0xBE, "vfnmsub", "ps">; defm VFNMSUBPD : fma_forms<0x9E, 0xAE, 0xBE, "vfnmsub", "pd">, VEX_W; } + +//===----------------------------------------------------------------------===// +// FMA4 - AMD 4 operand Fused Multiply-Add instructions +//===----------------------------------------------------------------------===// + + +multiclass fma4s opc, string OpcodeStr> { + def rr : FMA4, XOP_W; + def rm : FMA4, XOP_W; + def mr : FMA4; + +} + +let isAsmParserOnly = 1 in { + defm VFMADDSD4 : fma4s<0x6B, "vfmaddsd">; +} + +// FMA4 Intrinsics patterns + +def : Pat<(int_x86_fma4_vfmadd_sd VR128:$src1, VR128:$src2, VR128:$src3), + (VFMADDSD4rr VR128:$src1, VR128:$src2, VR128:$src3)>; +def : Pat<(int_x86_fma4_vfmadd_sd VR128:$src1, VR128:$src2, + (alignedloadv2f64 addr:$src3)), + (VFMADDSD4rm VR128:$src1, VR128:$src2, addr:$src3)>; +def : Pat<(int_x86_fma4_vfmadd_sd VR128:$src1, (alignedloadv2f64 addr:$src2), + VR128:$src3), + (VFMADDSD4mr VR128:$src1, addr:$src2, VR128:$src3)>; Modified: llvm/trunk/lib/Target/X86/X86InstrFormats.td URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86InstrFormats.td?rev=145133&r1=145132&r2=145133&view=diff ============================================================================== --- llvm/trunk/lib/Target/X86/X86InstrFormats.td (original) +++ llvm/trunk/lib/Target/X86/X86InstrFormats.td Fri Nov 25 13:33:42 2011 @@ -118,7 +118,7 @@ class VEX_L { bit hasVEX_L = 1; } class VEX_LIG { bit ignoresVEX_L = 1; } class Has3DNow0F0FOpcode { bit has3DNow0F0FOpcode = 1; } - +class XOP_W { bit hasXOP_WPrefix = 1; } class X86Inst opcod, Format f, ImmType i, dag outs, dag ins, string AsmStr, Domain d = GenericDomain> : Instruction { @@ -158,6 +158,7 @@ bit hasVEX_L = 0; // Does this inst use large (256-bit) registers? bit ignoresVEX_L = 0; // Does this instruction ignore the L-bit bit has3DNow0F0FOpcode =0;// Wacky 3dNow! encoding? + bit hasXOP_WPrefix = 0; // Same bit as VEX_W, but used for swapping operands // TSFlags layout should be kept in sync with X86InstrInfo.h. let TSFlags{5-0} = FormBits; @@ -179,6 +180,7 @@ let TSFlags{38} = hasVEX_L; let TSFlags{39} = ignoresVEX_L; let TSFlags{40} = has3DNow0F0FOpcode; + let TSFlags{41} = hasXOP_WPrefix; } class PseudoI pattern> @@ -496,6 +498,12 @@ : I, T8, OpSize, VEX_4V, Requires<[HasFMA3]>; +// FMA4 Instruction Templates +class FMA4 o, Format F, dag outs, dag ins, string asm, + listpattern> + : I, TA, + OpSize, VEX_4V, VEX_I8IMM, Requires<[HasFMA4]>; + // X86-64 Instruction templates... // Added: llvm/trunk/test/CodeGen/X86/fma4-intrinsics-x86_64.ll URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/fma4-intrinsics-x86_64.ll?rev=145133&view=auto ============================================================================== --- llvm/trunk/test/CodeGen/X86/fma4-intrinsics-x86_64.ll (added) +++ llvm/trunk/test/CodeGen/X86/fma4-intrinsics-x86_64.ll Fri Nov 25 13:33:42 2011 @@ -0,0 +1,9 @@ +; RUN: llc < %s -mtriple=x86_64-unknown-unknown -march=x86-64 -mattr=fma4 | FileCheck %s + +define < 2 x double > @test_x86_fma4_vfmadd_sd(< 2 x double > %a0, < 2 x double > %a1, < 2 x double > %a2) { + ; CHECK: vfmaddsd + %res = call < 2 x double > @llvm.x86.fma4.vfmadd.sd(< 2 x double > %a0, < 2 x double > %a1, < 2 x double > %a2) ; [#uses=1] + ret < 2 x double > %res +} +declare < 2 x double > @llvm.x86.fma4.vfmadd.sd(< 2 x double >, < 2 x double >, < 2 x double >) nounwind readnone + Added: llvm/trunk/test/MC/X86/x86_64-fma4-encoding.s URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/MC/X86/x86_64-fma4-encoding.s?rev=145133&view=auto ============================================================================== --- llvm/trunk/test/MC/X86/x86_64-fma4-encoding.s (added) +++ llvm/trunk/test/MC/X86/x86_64-fma4-encoding.s Fri Nov 25 13:33:42 2011 @@ -0,0 +1,13 @@ +// RUN: llvm-mc -triple x86_64-unknown-unknown --show-encoding %s | FileCheck %s + +// CHECK: vfmaddsd (%rcx), %xmm1, %xmm0, %xmm0 +// CHECK: encoding: [0xc4,0xe3,0xf9,0x6b,0x01,0x10] + vfmaddsd (%rcx), %xmm1, %xmm0, %xmm0 + +// CHECK: vfmaddsd %xmm1, (%rcx), %xmm0, %xmm0 +// CHECK: encoding: [0xc4,0xe3,0x79,0x6b,0x01,0x10] + vfmaddsd %xmm1, (%rcx),%xmm0, %xmm0 + +// CHECK: vfmaddsd %xmm2, %xmm1, %xmm0, %xmm0 +// CHECK: encoding: [0xc4,0xe3,0xf9,0x6b,0xc2,0x10] + vfmaddsd %xmm2, %xmm1, %xmm0, %xmm0 From bruno.cardoso at gmail.com Fri Nov 25 13:36:58 2011 From: bruno.cardoso at gmail.com (Bruno Cardoso Lopes) Date: Fri, 25 Nov 2011 17:36:58 -0200 Subject: [llvm-commits] Initial patch for FMA4 support In-Reply-To: <1322086398.5675.YahooMailNeo@web161520.mail.bf1.yahoo.com> References: <1322002078.40338.YahooMailNeo@web161508.mail.bf1.yahoo.com> <1322083486.11523.YahooMailNeo@web161518.mail.bf1.yahoo.com> <1322086398.5675.YahooMailNeo@web161520.mail.bf1.yahoo.com> Message-ID: Committed r145133 On Wed, Nov 23, 2011 at 8:13 PM, Jan Sjodin wrote: > Here is the updated patch. > > - Jan > > > > ----- Original Message ----- >> From: Bruno Cardoso Lopes >> To: Jan Sjodin >> Cc: "llvm-commits at cs.uiuc.edu" >> Sent: Wednesday, November 23, 2011 4:30 PM >> Subject: Re: [llvm-commits] Initial patch for FMA4 support >> >> On Wed, Nov 23, 2011 at 7:24 PM, Jan Sjodin wrote: >>> ?Thanks Bruno for the quick review. >>> >>> >>>> There's no specific reason in this case to have the "Int" >> forms: >>> >>>> >>>> +multiclass fma4s_Int opc, string OpcodeStr, Intrinsic >> Int, >>>> +??? ? ? PatFrag ld_frag> { >>>> ... >>>> +defm Int_VFMADDSD4? : fma4s_Int<0x6B, "vfmaddsd", >>>> int_x86_fma4_vfmadd_sd, alignedloadv2f64>; >>>> >>>> Instead, just write patterns to match the intrinsics with the >>>> previously defined FMA4 instructions. >>> >>> >>> ?Okay, will do. >>> >>> >>>> >>>> ? ? ???if (HasVEX_4V) >>>> ? ? ? ???++FirstMemOp;// Skip the register source (which is encoded in >>>> VEX_VVVV). >>>> +? ? ? if (HasXOP_W) >>>> +? ? ? ? ++FirstMemOp;// Skip the register source (which is encoded in >> I8IMM). >>>> >>>> Use " if (HasVEX_4V || HasXOP_W)" and update the comment >> properly. >>> >>> >>> ?It actually increments twice if both VEX_4V and HasXOP_W are true, not by >> one. >>> >>> ?I could update the comment to make it more clear e.g.: >>> >>> ?// Skip second register source (which is encoded in I8IMM) >>> >>> ?If you want it written a different way let me know. >> >> Oops. No need, it's fine this way! :) >> >>> >>>> +#include "llvm/Support/Debug.h" >>>> >>>> Are you sure you need this? >>> >>> ?No, forgot to remove, will fix. >>> >>> >>>> >>>> +? ? } else { >>>> +? ? ? CurOp += AddrOperands + 1; >>>> +? ? ? if (HasVEX_4VOp3) >>>> +??? ++CurOp; >>>> +? ? } >>>> >>>> "++CurOp" lacks proper indentation! >>> >>> ?Will fix. >>> >>> >>> ?- Jan >>> >>> >> >> >> >> -- >> Bruno Cardoso Lopes >> http://www.brunocardoso.cc >> -- Bruno Cardoso Lopes http://www.brunocardoso.cc From sabre at nondot.org Fri Nov 25 14:28:16 2011 From: sabre at nondot.org (Chris Lattner) Date: Fri, 25 Nov 2011 20:28:16 -0000 Subject: [llvm-commits] [llvm] r145134 - /llvm/trunk/docs/ReleaseNotes.html Message-ID: <20111125202816.4DBFB2A6C12E@llvm.org> Author: lattner Date: Fri Nov 25 14:28:16 2011 New Revision: 145134 URL: http://llvm.org/viewvc/llvm-project?rev=145134&view=rev Log: add faust Modified: llvm/trunk/docs/ReleaseNotes.html Modified: llvm/trunk/docs/ReleaseNotes.html URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes.html?rev=145134&r1=145133&r2=145134&view=diff ============================================================================== --- llvm/trunk/docs/ReleaseNotes.html (original) +++ llvm/trunk/docs/ReleaseNotes.html Fri Nov 25 14:28:16 2011 @@ -410,6 +410,21 @@ +

FAUST Real-Time Audio Signal Processing Language

+ +

FAUST is a compiled language for + real-time audio signal processing. The name FAUST stands for Functional + AUdio STream. Its programming model combines two approaches: functional + programming and block diagram composition. In addition with the C, C++, Java + output formats, the Faust compiler can now generate LLVM bitcode, and works + with LLVM 2.7-3.0. +

+ +

Glasgow Haskell Compiler (GHC)

From sabre at nondot.org Fri Nov 25 14:33:27 2011 From: sabre at nondot.org (Chris Lattner) Date: Fri, 25 Nov 2011 20:33:27 -0000 Subject: [llvm-commits] [llvm] r145135 - /llvm/trunk/docs/ReleaseNotes.html Message-ID: <20111125203327.DFF3C2A6C12E@llvm.org> Author: lattner Date: Fri Nov 25 14:33:27 2011 New Revision: 145135 URL: http://llvm.org/viewvc/llvm-project?rev=145135&view=rev Log: add some notes Modified: llvm/trunk/docs/ReleaseNotes.html Modified: llvm/trunk/docs/ReleaseNotes.html URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes.html?rev=145135&r1=145134&r2=145135&view=diff ============================================================================== --- llvm/trunk/docs/ReleaseNotes.html (original) +++ llvm/trunk/docs/ReleaseNotes.html Fri Nov 25 14:33:27 2011 @@ -752,6 +752,9 @@ Better code generation for Cortex-A9 Many APIs take ArrayRef's now. Pass manager extension API. + + +Information about branch probability and basic block frequency is now available within LLVM based on a combination of static branch prediction heuristics and __builtin_expect calls. That information is currently used for register spill placement and if-conversion, with additional optimizations planned for future releases. The same frameworks are intended for eventual use with profile-guided optimization, but that is not yet implemented. --> From sabre at nondot.org Fri Nov 25 14:36:17 2011 From: sabre at nondot.org (Chris Lattner) Date: Fri, 25 Nov 2011 20:36:17 -0000 Subject: [llvm-commits] [llvm] r145136 - /llvm/trunk/docs/ReleaseNotes.html Message-ID: <20111125203617.CA98C2A6C12E@llvm.org> Author: lattner Date: Fri Nov 25 14:36:17 2011 New Revision: 145136 URL: http://llvm.org/viewvc/llvm-project?rev=145136&view=rev Log: add a user Modified: llvm/trunk/docs/ReleaseNotes.html Modified: llvm/trunk/docs/ReleaseNotes.html URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes.html?rev=145136&r1=145135&r2=145136&view=diff ============================================================================== --- llvm/trunk/docs/ReleaseNotes.html (original) +++ llvm/trunk/docs/ReleaseNotes.html Fri Nov 25 14:36:17 2011 @@ -492,6 +492,22 @@ example program. ispc is licensed under the BSD license.

+ + +

The Julia Programming Language

+ +

Julia is a high-level, + high-performance dynamic language for technical + computing. It provides a sophisticated compiler, distributed parallel + execution, numerical accuracy, and an extensive mathematical function + library. The compiler uses type inference to generate fast code + without any type declarations, and uses LLVM's optimization passes and + JIT compiler. The language is designed around multiple dispatch, + giving programs a large degree of flexibility. It is ready for use on many + kinds of problems.

LanguageKit and Pragmatic Smalltalk

From resistor at mac.com Fri Nov 25 14:58:54 2011 From: resistor at mac.com (Owen Anderson) Date: Fri, 25 Nov 2011 12:58:54 -0800 Subject: [llvm-commits] MachOObjectFile fix functions In-Reply-To: <6AE1604EE3EC5F4296C096518C6B77EE1AA49B09EF@mail.accesssoftek.com> References: <6AE1604EE3EC5F4296C096518C6B77EE1805B07349@mail.accesssoftek.com> <6AE1604EE3EC5F4296C096518C6B77EE1805C8FA97@mail.accesssoftek.com> <6AE1604EE3EC5F4296C096518C6B77EE18123D6BC3@mail.accesssoftek.com> <6AE1604EE3EC5F4296C096518C6B77EE1AA49B09EF@mail.accesssoftek.com> Message-ID: Danil, I'm good with this version. Go ahead and apply. --Owen On Nov 24, 2011, at 12:05 PM, Danil Malyshev wrote: > ping > > From: Danil Malyshev > Sent: Saturday, November 12, 2011 3:00 AM > To: 'Owen Anderson' > Cc: 'llvm-commits at cs.uiuc.edu' > Subject: RE: [llvm-commits] MachOObjectFile fix functions > > Hello Owen > > > I see your reasoning here, but it scares me a little bit to have methods with the same name that do different things. > > I think we should either rename them to be obviously different, or pick a consistent meaning for all of them. > > I have renamed symbol.getOffset() as getFileOffset(). > Please find attached the changed patch. > > Regards, > Danil > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20111125/52b4d174/attachment.html From benny.kra at googlemail.com Fri Nov 25 15:03:06 2011 From: benny.kra at googlemail.com (Benjamin Kramer) Date: Fri, 25 Nov 2011 21:03:06 -0000 Subject: [llvm-commits] [llvm] r145137 - /llvm/trunk/docs/ReleaseNotes.html Message-ID: <20111125210306.6E01B2A6C12D@llvm.org> Author: d0k Date: Fri Nov 25 15:03:06 2011 New Revision: 145137 URL: http://llvm.org/viewvc/llvm-project?rev=145137&view=rev Log: Remove ZooLib from the projects list. I don't see how the project is using LLVM and we really can't list every user of the clang analyzer. Sorry. Modified: llvm/trunk/docs/ReleaseNotes.html Modified: llvm/trunk/docs/ReleaseNotes.html URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes.html?rev=145137&r1=145136&r2=145137&view=diff ============================================================================== --- llvm/trunk/docs/ReleaseNotes.html (original) +++ llvm/trunk/docs/ReleaseNotes.html Fri Nov 25 15:03:06 2011 @@ -700,24 +700,6 @@ - -

The ZooLib C++ Cross-Platform Application Framework

- -

ZooLib is Open Source under the MIT - License. It provides GUI, filesystem access, TCP networking, thread-safe - memory management, threading and locking for Mac OS X, Classic Mac OS, - Microsoft Windows, POSIX operating systems with X11, BeOS, Haiku, Apple's iOS - and Research in Motion's BlackBerry.

- -

My current work is to use CLang's static analyzer to improve ZooLib's code - quality. I also plan to set up LLVM compiles of the demo programs and test - programs using CLang and LLVM on all the platforms that CLang, LLVM and - ZooLib all support.

- -

- From benny.kra at googlemail.com Fri Nov 25 15:26:00 2011 From: benny.kra at googlemail.com (Benjamin Kramer) Date: Fri, 25 Nov 2011 21:26:00 -0000 Subject: [llvm-commits] [llvm] r145138 - /llvm/trunk/docs/ReleaseNotes.html Message-ID: <20111125212600.5E61D2A6C12D@llvm.org> Author: d0k Date: Fri Nov 25 15:26:00 2011 New Revision: 145138 URL: http://llvm.org/viewvc/llvm-project?rev=145138&view=rev Log: shpelling Modified: llvm/trunk/docs/ReleaseNotes.html Modified: llvm/trunk/docs/ReleaseNotes.html URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes.html?rev=145138&r1=145137&r2=145138&view=diff ============================================================================== --- llvm/trunk/docs/ReleaseNotes.html (original) +++ llvm/trunk/docs/ReleaseNotes.html Fri Nov 25 15:26:00 2011 @@ -520,7 +520,7 @@ its own interpreter. Pragmatic Smalltalk is a dialect of Smalltalk, built on top of LanguageKit, that interfaces directly with Objective-C, sharing the same object representation and message sending behaviour. These projects are - developed as part of the Étoié desktop environment.

+ developed as part of the Étoilé desktop environment.

@@ -802,7 +802,7 @@

Converting from the old EH API to the new EH API is rather simple, because a lot of complexity has been removed. The two intrinsics, @llvm.eh.exception and @llvm.eh.selector have been - superceded by the landingpad instruction. Instead of generating + superseded by the landingpad instruction. Instead of generating a call to @llvm.eh.exception and @llvm.eh.selector:

@@ -1112,7 +1112,7 @@ "load volatile"/"store volatile". The old syntax ("volatile load"/"volatile store") is still accepted, but is now considered deprecated.

Merge the delay slot filling logic that is duplicated into (at least) + the Sparc and Mips backends into a single target independent pass. + Likewise, the branch shortening logic in several targets should be merged + together into one pass.

Implement 'stack slot coloring' to allocate two frame indexes to the same stack offset if their live ranges don't overlap. This can reuse a bunch of analysis machinery from LiveIntervals. Making the stack smaller is good From sabre at nondot.org Sun Nov 27 02:18:55 2011 From: sabre at nondot.org (Chris Lattner) Date: Sun, 27 Nov 2011 08:18:55 -0000 Subject: [llvm-commits] [llvm] r145176 - /llvm/trunk/lib/VMCore/AutoUpgrade.cpp Message-ID: <20111127081855.5A1261BE002@llvm.org> Author: lattner Date: Sun Nov 27 02:18:55 2011 New Revision: 145176 URL: http://llvm.org/viewvc/llvm-project?rev=145176&view=rev Log: The llvm.atomic intrinsics *were* removed in LLVM 3.0 (in r141333), remove the autoupgrade logic for 2.9 and before. Modified: llvm/trunk/lib/VMCore/AutoUpgrade.cpp Modified: llvm/trunk/lib/VMCore/AutoUpgrade.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/VMCore/AutoUpgrade.cpp?rev=145176&r1=145175&r2=145176&view=diff ============================================================================== --- llvm/trunk/lib/VMCore/AutoUpgrade.cpp (original) +++ llvm/trunk/lib/VMCore/AutoUpgrade.cpp Sun Nov 27 02:18:55 2011 @@ -40,21 +40,6 @@ switch (Name[0]) { default: break; - case 'a': - if (Name.startswith("atomic.cmp.swap") || - Name.startswith("atomic.swap") || - Name.startswith("atomic.load.add") || - Name.startswith("atomic.load.sub") || - Name.startswith("atomic.load.and") || - Name.startswith("atomic.load.nand") || - Name.startswith("atomic.load.or") || - Name.startswith("atomic.load.xor") || - Name.startswith("atomic.load.max") || - Name.startswith("atomic.load.min") || - Name.startswith("atomic.load.umax") || - Name.startswith("atomic.load.umin")) - return true; - break; case 'm': if (Name == "memory.barrier") return true; @@ -96,59 +81,7 @@ assert(F && "CallInst has no function associated with it."); if (!NewFn) { - if (F->getName().startswith("llvm.atomic.cmp.swap")) { - IRBuilder<> Builder(C); - Builder.SetInsertPoint(CI->getParent(), CI); - Value *Val = Builder.CreateAtomicCmpXchg(CI->getArgOperand(0), - CI->getArgOperand(1), - CI->getArgOperand(2), - Monotonic); - - // Replace intrinsic. - Val->takeName(CI); - if (!CI->use_empty()) - CI->replaceAllUsesWith(Val); - CI->eraseFromParent(); - } else if (F->getName().startswith("llvm.atomic")) { - IRBuilder<> Builder(C); - Builder.SetInsertPoint(CI->getParent(), CI); - - AtomicRMWInst::BinOp Op; - if (F->getName().startswith("llvm.atomic.swap")) - Op = AtomicRMWInst::Xchg; - else if (F->getName().startswith("llvm.atomic.load.add")) - Op = AtomicRMWInst::Add; - else if (F->getName().startswith("llvm.atomic.load.sub")) - Op = AtomicRMWInst::Sub; - else if (F->getName().startswith("llvm.atomic.load.and")) - Op = AtomicRMWInst::And; - else if (F->getName().startswith("llvm.atomic.load.nand")) - Op = AtomicRMWInst::Nand; - else if (F->getName().startswith("llvm.atomic.load.or")) - Op = AtomicRMWInst::Or; - else if (F->getName().startswith("llvm.atomic.load.xor")) - Op = AtomicRMWInst::Xor; - else if (F->getName().startswith("llvm.atomic.load.max")) - Op = AtomicRMWInst::Max; - else if (F->getName().startswith("llvm.atomic.load.min")) - Op = AtomicRMWInst::Min; - else if (F->getName().startswith("llvm.atomic.load.umax")) - Op = AtomicRMWInst::UMax; - else if (F->getName().startswith("llvm.atomic.load.umin")) - Op = AtomicRMWInst::UMin; - else - llvm_unreachable("Unknown atomic"); - - Value *Val = Builder.CreateAtomicRMW(Op, CI->getArgOperand(0), - CI->getArgOperand(1), - Monotonic); - - // Replace intrinsic. - Val->takeName(CI); - if (!CI->use_empty()) - CI->replaceAllUsesWith(Val); - CI->eraseFromParent(); - } else if (F->getName() == "llvm.memory.barrier") { + if (F->getName() == "llvm.memory.barrier") { IRBuilder<> Builder(C); Builder.SetInsertPoint(CI->getParent(), CI); From sabre at nondot.org Sun Nov 27 02:32:32 2011 From: sabre at nondot.org (Chris Lattner) Date: Sun, 27 Nov 2011 08:32:32 -0000 Subject: [llvm-commits] [llvm] r145177 - /llvm/trunk/docs/ReleaseNotes.html Message-ID: <20111127083232.BC7581BE002@llvm.org> Author: lattner Date: Sun Nov 27 02:32:32 2011 New Revision: 145177 URL: http://llvm.org/viewvc/llvm-project?rev=145177&view=rev Log: add some final random notes, I've completed my pass over all the commits. I'll work on turning this into something intelligible tomorrow. Modified: llvm/trunk/docs/ReleaseNotes.html Modified: llvm/trunk/docs/ReleaseNotes.html URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes.html?rev=145177&r1=145176&r2=145177&view=diff ============================================================================== --- llvm/trunk/docs/ReleaseNotes.html (original) +++ llvm/trunk/docs/ReleaseNotes.html Sun Nov 27 02:32:32 2011 @@ -740,14 +740,14 @@
-
llvm-gcc is gone
+
llvm-gcc is gone. LLVM's configure script doesn't depend on llvm-gcc anymore, clean layering.

LLVM 3.0 includes several major new capabilities:

@@ -1150,8 +1162,7 @@ from the previous release.

-
The LLVMC front end code was removed while separating - out language independence.
+
The LLVMC meta compiler driver was removed.

The LowerSetJmp pass wasn't used effectively by any target and has been removed.

The old TailDup pass was not used in the standard pipeline From sabre at nondot.org Sun Nov 27 02:42:07 2011 From: sabre at nondot.org (Chris Lattner) Date: Sun, 27 Nov 2011 08:42:07 -0000 Subject: [llvm-commits] [llvm] r145178 - /llvm/trunk/lib/VMCore/AutoUpgrade.cpp Message-ID: <20111127084207.98FF11BE002@llvm.org> Author: lattner Date: Sun Nov 27 02:42:07 2011 New Revision: 145178 URL: http://llvm.org/viewvc/llvm-project?rev=145178&view=rev Log: Eli managed to kill off llvm.membarrier in llvm 3.0 also, this means that mainline needs no autoupgrade logic for intrinsics yet, woohoo! Modified: llvm/trunk/lib/VMCore/AutoUpgrade.cpp Modified: llvm/trunk/lib/VMCore/AutoUpgrade.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/VMCore/AutoUpgrade.cpp?rev=145178&r1=145177&r2=145178&view=diff ============================================================================== --- llvm/trunk/lib/VMCore/AutoUpgrade.cpp (original) +++ llvm/trunk/lib/VMCore/AutoUpgrade.cpp Sun Nov 27 02:42:07 2011 @@ -37,13 +37,10 @@ if (Name.size() <= 8 || !Name.startswith("llvm.")) return false; Name = Name.substr(5); // Strip off "llvm." - + switch (Name[0]) { default: break; - case 'm': - if (Name == "memory.barrier") - return true; - break; + // SOMEDAY: Add some. } // This may not belong here. This function is effectively being overloaded @@ -75,38 +72,15 @@ // order to seamlessly integrate with existing context. void llvm::UpgradeIntrinsicCall(CallInst *CI, Function *NewFn) { Function *F = CI->getCalledFunction(); - LLVMContext &C = CI->getContext(); - ImmutableCallSite CS(CI); assert(F && "CallInst has no function associated with it."); - if (!NewFn) { - if (F->getName() == "llvm.memory.barrier") { - IRBuilder<> Builder(C); - Builder.SetInsertPoint(CI->getParent(), CI); - - // Note that this conversion ignores the "device" bit; it was not really - // well-defined, and got abused because nobody paid enough attention to - // get it right. In practice, this probably doesn't matter; application - // code generally doesn't need anything stronger than - // SequentiallyConsistent (and realistically, SequentiallyConsistent - // is lowered to a strong enough barrier for almost anything). - - if (cast(CI->getArgOperand(1))->getZExtValue()) - Builder.CreateFence(SequentiallyConsistent); - else if (!cast(CI->getArgOperand(0))->getZExtValue()) - Builder.CreateFence(Release); - else if (!cast(CI->getArgOperand(3))->getZExtValue()) - Builder.CreateFence(Acquire); - else - Builder.CreateFence(AcquireRelease); - - // Remove intrinsic. - CI->eraseFromParent(); - } else { - llvm_unreachable("Unknown function for CallInst upgrade."); - } - return; + if (NewFn) return; + + if (F->getName() == "llvm.something eventually") { + // UPGRADE HERE. + } else { + llvm_unreachable("Unknown function for CallInst upgrade."); } } From chandlerc at gmail.com Sun Nov 27 03:22:53 2011 From: chandlerc at gmail.com (Chandler Carruth) Date: Sun, 27 Nov 2011 09:22:53 -0000 Subject: [llvm-commits] [llvm] r145179 - in /llvm/trunk: lib/CodeGen/MachineBlockPlacement.cpp test/CodeGen/X86/block-placement.ll Message-ID: <20111127092253.6897C1BE002@llvm.org> Author: chandlerc Date: Sun Nov 27 03:22:53 2011 New Revision: 145179 URL: http://llvm.org/viewvc/llvm-project?rev=145179&view=rev Log: Rework a bit of the implementation of loop block rotation to not rely so heavily on AnalyzeBranch. That routine doesn't behave as we want given that rotation occurs mid-way through re-ordering the function. Instead merely check that there are not unanalyzable branching constructs present, and then reason about the CFG via successor lists. This actually simplifies my mental model for all of this as well. The concrete result is that we now will rotate more loop chains. I've added a test case from Olden highlighting the effect. There is still a bit more to do here though in order to regain all of the performance in Olden. Modified: llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp llvm/trunk/test/CodeGen/X86/block-placement.ll Modified: llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp?rev=145179&r1=145178&r2=145179&view=diff ============================================================================== --- llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp (original) +++ llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp Sun Nov 27 03:22:53 2011 @@ -585,12 +585,14 @@ // We need to analyze the branch and determine if rotating the loop will // completely remove a branch. We bail if the analysis fails or we don't find - // an unconditional backedge. + // an unconditional backedge. Note that this has to handle cases where the + // original order was rotated, and the chain has un-done it. As a result, + // there may not (yet) be the uncondiationl branch, but we can tell whether + // one will be added when updating the terminators. SmallVector Cond; MachineBasicBlock *TBB = 0, *FBB = 0; - if (TII->AnalyzeBranch(*Latch, TBB, FBB, Cond) || !TBB || FBB || !Cond.empty()) + if (TII->AnalyzeBranch(*Latch, TBB, FBB, Cond) || !Cond.empty()) return; - assert(TBB == Header && "Found backedge that doesn't go to the header!"); // Next we need to find a split point. This rotate algorithm is *very* // narrow, and it only tries to do the rotate when it can find a split point @@ -604,27 +606,35 @@ I != E; ++I) { Cond.clear(); TBB = FBB = 0; - if (TII->AnalyzeBranch(**I, TBB, FBB, Cond) || !TBB || Cond.empty()) + // Ensure that this is a block with a conditional branch which we can + // analyze and re-form after rotating the loop. While it might be tempting + // to use the TBB or FBB output parameters from this, they will often be + // lies as they are only correct after the terminators have been updated, + // and we are mid-chain formation. + if (TII->AnalyzeBranch(**I, TBB, FBB, Cond) || Cond.empty()) continue; - // Swap things so that the in-loop successor is always in FBB or is an - // implicit fallthrough. - if (FBB && !LoopBlockSet.count(FBB)) - std::swap(TBB, FBB); - // Check that we actually have a loop exit branch. - // FIXME: We should probably just use the LoopInfo for this. - if (!LoopBlockSet.count(TBB) && (!FBB || !LoopBlockSet.count(FBB))) { - // This is a very arbitrary restriction, but it ensures we don't disrupt - // the existing chain layout. We insist that the in-loop successor is - // chained as a fallthrough successor (even if the branch hasn't been - // updated to reflect that yet). - if (FBB && FBB != *llvm::prior(I)) - continue; - NewBottom = *I; - NewTop = *llvm::prior(I); - SplitIt = I.base(); - break; + // See if this block is an exiting block from the loop. LoopInfo provides + // a nice API for this, but it's actuall N*M runtime where N is the number + // of blocks in the loop and M is the number of successors. We can + // eliminate the N by doing this ourselves. + // FIXME: The LoopInfo datastructure should be improved for these types of + // queries. + MachineBasicBlock *ExitB = 0; + for (MachineBasicBlock::succ_iterator SI = (*I)->succ_begin(), SE = (*I)->succ_end(); + SI != SE; ++SI) { + if (!(*SI)->isLandingPad() && *SI != *I && !LoopBlockSet.count(*SI)) { + ExitB = *SI; + break; + } } + if (!ExitB) + continue; + + NewBottom = *I; + NewTop = *llvm::prior(I); + SplitIt = I.base(); + break; } if (!NewBottom || !NewTop || SplitIt == LoopChain.end() || SplitIt == LoopChain.begin()) Modified: llvm/trunk/test/CodeGen/X86/block-placement.ll URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/block-placement.ll?rev=145179&r1=145178&r2=145179&view=diff ============================================================================== --- llvm/trunk/test/CodeGen/X86/block-placement.ll (original) +++ llvm/trunk/test/CodeGen/X86/block-placement.ll Sun Nov 27 03:22:53 2011 @@ -199,6 +199,44 @@ ret i32 %base } +define void @test_loop_rotate_reversed_blocks() { +; This test case (greatly reduced from an Olden bencmark) ensures that the loop +; rotate implementation doesn't assume that loops are laid out in a particular +; order. The first loop will get split into two basic blocks, with the loop +; header coming after the loop latch. +; +; CHECK: test_loop_rotate_reversed_blocks +; CHECK: %entry +; Look for a jump into the middle of the loop, and no branches mid-way. +; CHECK: jmp +; CHECK: %loop1 +; CHECK-NOT: j{{\w*}} .LBB{{.*}} +; CHECK: %loop1 +; CHECK: je + +entry: + %cond1 = load volatile i1* undef + br i1 %cond1, label %loop2.preheader, label %loop1 + +loop1: + call i32 @f() + %cond2 = load volatile i1* undef + br i1 %cond2, label %loop2.preheader, label %loop1 + +loop2.preheader: + call i32 @f() + %cond3 = load volatile i1* undef + br i1 %cond3, label %exit, label %loop2 + +loop2: + call i32 @f() + %cond4 = load volatile i1* undef + br i1 %cond4, label %exit, label %loop2 + +exit: + ret void +} + define i32 @test_loop_align(i32 %i, i32* %a) { ; Check that we provide basic loop body alignment with the block placement ; pass. @@ -567,8 +605,8 @@ ; CHECK: test_unnatural_cfg_backwards_inner_loop ; CHECK: %entry ; CHECK: %body -; CHECK: %loop1 ; CHECK: %loop2b +; CHECK: %loop1 ; CHECK: %loop2a entry: From dmalyshev at accesssoftek.com Sun Nov 27 04:12:52 2011 From: dmalyshev at accesssoftek.com (Danil Malyshev) Date: Sun, 27 Nov 2011 10:12:52 -0000 Subject: [llvm-commits] [llvm] r145180 - in /llvm/trunk: include/llvm-c/Object.h include/llvm/Object/COFF.h include/llvm/Object/MachO.h include/llvm/Object/ObjectFile.h lib/Object/COFFObjectFile.cpp lib/Object/ELFObjectFile.cpp lib/Object/MachOObjectFile.cpp lib/Object/Object.cpp tools/llvm-nm/llvm-nm.cpp tools/llvm-objdump/MachODump.cpp tools/llvm-objdump/llvm-objdump.cpp Message-ID: <20111127101252.8A1761BE002@llvm.org> Author: danil Date: Sun Nov 27 04:12:52 2011 New Revision: 145180 URL: http://llvm.org/viewvc/llvm-project?rev=145180&view=rev Log: Fixed ObjectFile functions: - getSymbolOffset() renamed as getSymbolFileOffset() - getSymbolFileOffset(), getSymbolAddress(), getRelocationAddress() returns same result for ELFObjectFile, MachOObjectFile and COFFObjectFile. - added getRelocationOffset() - fixed MachOObjectFile::getSymbolSize() - fixed MachOObjectFile::getSymbolSection() - fixed MachOObjectFile::getSymbolOffset() for symbols without section data. Modified: llvm/trunk/include/llvm-c/Object.h llvm/trunk/include/llvm/Object/COFF.h llvm/trunk/include/llvm/Object/MachO.h llvm/trunk/include/llvm/Object/ObjectFile.h llvm/trunk/lib/Object/COFFObjectFile.cpp llvm/trunk/lib/Object/ELFObjectFile.cpp llvm/trunk/lib/Object/MachOObjectFile.cpp llvm/trunk/lib/Object/Object.cpp llvm/trunk/tools/llvm-nm/llvm-nm.cpp llvm/trunk/tools/llvm-objdump/MachODump.cpp llvm/trunk/tools/llvm-objdump/llvm-objdump.cpp Modified: llvm/trunk/include/llvm-c/Object.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm-c/Object.h?rev=145180&r1=145179&r2=145180&view=diff ============================================================================== --- llvm/trunk/include/llvm-c/Object.h (original) +++ llvm/trunk/include/llvm-c/Object.h Sun Nov 27 04:12:52 2011 @@ -73,11 +73,12 @@ // SymbolRef accessors const char *LLVMGetSymbolName(LLVMSymbolIteratorRef SI); uint64_t LLVMGetSymbolAddress(LLVMSymbolIteratorRef SI); -uint64_t LLVMGetSymbolOffset(LLVMSymbolIteratorRef SI); +uint64_t LLVMGetSymbolFileOffset(LLVMSymbolIteratorRef SI); uint64_t LLVMGetSymbolSize(LLVMSymbolIteratorRef SI); // RelocationRef accessors uint64_t LLVMGetRelocationAddress(LLVMRelocationIteratorRef RI); +uint64_t LLVMGetRelocationOffset(LLVMRelocationIteratorRef RI); LLVMSymbolIteratorRef LLVMGetRelocationSymbol(LLVMRelocationIteratorRef RI); uint64_t LLVMGetRelocationType(LLVMRelocationIteratorRef RI); // NOTE: Caller takes ownership of returned string of the two Modified: llvm/trunk/include/llvm/Object/COFF.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Object/COFF.h?rev=145180&r1=145179&r2=145180&view=diff ============================================================================== --- llvm/trunk/include/llvm/Object/COFF.h (original) +++ llvm/trunk/include/llvm/Object/COFF.h Sun Nov 27 04:12:52 2011 @@ -105,7 +105,7 @@ protected: virtual error_code getSymbolNext(DataRefImpl Symb, SymbolRef &Res) const; virtual error_code getSymbolName(DataRefImpl Symb, StringRef &Res) const; - virtual error_code getSymbolOffset(DataRefImpl Symb, uint64_t &Res) const; + virtual error_code getSymbolFileOffset(DataRefImpl Symb, uint64_t &Res) const; virtual error_code getSymbolAddress(DataRefImpl Symb, uint64_t &Res) const; virtual error_code getSymbolSize(DataRefImpl Symb, uint64_t &Res) const; virtual error_code getSymbolNMTypeChar(DataRefImpl Symb, char &Res) const; @@ -135,6 +135,8 @@ RelocationRef &Res) const; virtual error_code getRelocationAddress(DataRefImpl Rel, uint64_t &Res) const; + virtual error_code getRelocationOffset(DataRefImpl Rel, + uint64_t &Res) const; virtual error_code getRelocationSymbol(DataRefImpl Rel, SymbolRef &Res) const; virtual error_code getRelocationType(DataRefImpl Rel, Modified: llvm/trunk/include/llvm/Object/MachO.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Object/MachO.h?rev=145180&r1=145179&r2=145180&view=diff ============================================================================== --- llvm/trunk/include/llvm/Object/MachO.h (original) +++ llvm/trunk/include/llvm/Object/MachO.h Sun Nov 27 04:12:52 2011 @@ -49,7 +49,7 @@ protected: virtual error_code getSymbolNext(DataRefImpl Symb, SymbolRef &Res) const; virtual error_code getSymbolName(DataRefImpl Symb, StringRef &Res) const; - virtual error_code getSymbolOffset(DataRefImpl Symb, uint64_t &Res) const; + virtual error_code getSymbolFileOffset(DataRefImpl Symb, uint64_t &Res) const; virtual error_code getSymbolAddress(DataRefImpl Symb, uint64_t &Res) const; virtual error_code getSymbolSize(DataRefImpl Symb, uint64_t &Res) const; virtual error_code getSymbolNMTypeChar(DataRefImpl Symb, char &Res) const; @@ -79,6 +79,8 @@ RelocationRef &Res) const; virtual error_code getRelocationAddress(DataRefImpl Rel, uint64_t &Res) const; + virtual error_code getRelocationOffset(DataRefImpl Rel, + uint64_t &Res) const; virtual error_code getRelocationSymbol(DataRefImpl Rel, SymbolRef &Res) const; virtual error_code getRelocationType(DataRefImpl Rel, Modified: llvm/trunk/include/llvm/Object/ObjectFile.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Object/ObjectFile.h?rev=145180&r1=145179&r2=145180&view=diff ============================================================================== --- llvm/trunk/include/llvm/Object/ObjectFile.h (original) +++ llvm/trunk/include/llvm/Object/ObjectFile.h Sun Nov 27 04:12:52 2011 @@ -104,6 +104,7 @@ error_code getNext(RelocationRef &Result) const; error_code getAddress(uint64_t &Result) const; + error_code getOffset(uint64_t &Result) const; error_code getSymbol(SymbolRef &Result) const; error_code getType(uint64_t &Result) const; @@ -195,7 +196,7 @@ error_code getName(StringRef &Result) const; error_code getAddress(uint64_t &Result) const; - error_code getOffset(uint64_t &Result) const; + error_code getFileOffset(uint64_t &Result) const; error_code getSize(uint64_t &Result) const; error_code getType(SymbolRef::Type &Result) const; @@ -254,7 +255,7 @@ virtual error_code getSymbolNext(DataRefImpl Symb, SymbolRef &Res) const = 0; virtual error_code getSymbolName(DataRefImpl Symb, StringRef &Res) const = 0; virtual error_code getSymbolAddress(DataRefImpl Symb, uint64_t &Res) const =0; - virtual error_code getSymbolOffset(DataRefImpl Symb, uint64_t &Res) const =0; + virtual error_code getSymbolFileOffset(DataRefImpl Symb, uint64_t &Res) const =0; virtual error_code getSymbolSize(DataRefImpl Symb, uint64_t &Res) const = 0; virtual error_code getSymbolType(DataRefImpl Symb, SymbolRef::Type &Res) const = 0; @@ -289,6 +290,8 @@ RelocationRef &Res) const = 0; virtual error_code getRelocationAddress(DataRefImpl Rel, uint64_t &Res) const =0; + virtual error_code getRelocationOffset(DataRefImpl Rel, + uint64_t &Res) const =0; virtual error_code getRelocationSymbol(DataRefImpl Rel, SymbolRef &Res) const = 0; virtual error_code getRelocationType(DataRefImpl Rel, @@ -363,8 +366,8 @@ return OwningObject->getSymbolAddress(SymbolPimpl, Result); } -inline error_code SymbolRef::getOffset(uint64_t &Result) const { - return OwningObject->getSymbolOffset(SymbolPimpl, Result); +inline error_code SymbolRef::getFileOffset(uint64_t &Result) const { + return OwningObject->getSymbolFileOffset(SymbolPimpl, Result); } inline error_code SymbolRef::getSize(uint64_t &Result) const { @@ -486,6 +489,10 @@ return OwningObject->getRelocationAddress(RelocationPimpl, Result); } +inline error_code RelocationRef::getOffset(uint64_t &Result) const { + return OwningObject->getRelocationOffset(RelocationPimpl, Result); +} + inline error_code RelocationRef::getSymbol(SymbolRef &Result) const { return OwningObject->getRelocationSymbol(RelocationPimpl, Result); } Modified: llvm/trunk/lib/Object/COFFObjectFile.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Object/COFFObjectFile.cpp?rev=145180&r1=145179&r2=145180&view=diff ============================================================================== --- llvm/trunk/lib/Object/COFFObjectFile.cpp (original) +++ llvm/trunk/lib/Object/COFFObjectFile.cpp Sun Nov 27 04:12:52 2011 @@ -101,7 +101,7 @@ return getSymbolName(symb, Result); } -error_code COFFObjectFile::getSymbolOffset(DataRefImpl Symb, +error_code COFFObjectFile::getSymbolFileOffset(DataRefImpl Symb, uint64_t &Result) const { const coff_symbol *symb = toSymb(Symb); const coff_section *Section = NULL; @@ -113,7 +113,7 @@ if (Type == 'U' || Type == 'w') Result = UnknownAddressOrSize; else if (Section) - Result = Section->VirtualAddress + symb->Value; + Result = Section->PointerToRawData + symb->Value; else Result = symb->Value; return object_error::success; @@ -131,11 +131,9 @@ if (Type == 'U' || Type == 'w') Result = UnknownAddressOrSize; else if (Section) - Result = reinterpret_cast(base() + - Section->PointerToRawData + - symb->Value); + Result = Section->VirtualAddress + symb->Value; else - Result = reinterpret_cast(base() + symb->Value); + Result = symb->Value; return object_error::success; } @@ -624,6 +622,11 @@ Res = toRel(Rel)->VirtualAddress; return object_error::success; } +error_code COFFObjectFile::getRelocationOffset(DataRefImpl Rel, + uint64_t &Res) const { + Res = toRel(Rel)->VirtualAddress; + return object_error::success; +} error_code COFFObjectFile::getRelocationSymbol(DataRefImpl Rel, SymbolRef &Res) const { const coff_relocation* R = toRel(Rel); Modified: llvm/trunk/lib/Object/ELFObjectFile.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Object/ELFObjectFile.cpp?rev=145180&r1=145179&r2=145180&view=diff ============================================================================== --- llvm/trunk/lib/Object/ELFObjectFile.cpp (original) +++ llvm/trunk/lib/Object/ELFObjectFile.cpp Sun Nov 27 04:12:52 2011 @@ -325,7 +325,7 @@ protected: virtual error_code getSymbolNext(DataRefImpl Symb, SymbolRef &Res) const; virtual error_code getSymbolName(DataRefImpl Symb, StringRef &Res) const; - virtual error_code getSymbolOffset(DataRefImpl Symb, uint64_t &Res) const; + virtual error_code getSymbolFileOffset(DataRefImpl Symb, uint64_t &Res) const; virtual error_code getSymbolAddress(DataRefImpl Symb, uint64_t &Res) const; virtual error_code getSymbolSize(DataRefImpl Symb, uint64_t &Res) const; virtual error_code getSymbolNMTypeChar(DataRefImpl Symb, char &Res) const; @@ -355,6 +355,8 @@ RelocationRef &Res) const; virtual error_code getRelocationAddress(DataRefImpl Rel, uint64_t &Res) const; + virtual error_code getRelocationOffset(DataRefImpl Rel, + uint64_t &Res) const; virtual error_code getRelocationSymbol(DataRefImpl Rel, SymbolRef &Res) const; virtual error_code getRelocationType(DataRefImpl Rel, @@ -462,7 +464,7 @@ template error_code ELFObjectFile - ::getSymbolOffset(DataRefImpl Symb, + ::getSymbolFileOffset(DataRefImpl Symb, uint64_t &Result) const { validateSymbol(Symb); const Elf_Sym *symb = getSymbol(Symb); @@ -486,7 +488,8 @@ case ELF::STT_FUNC: case ELF::STT_OBJECT: case ELF::STT_NOTYPE: - Result = symb->st_value; + Result = symb->st_value + + (Section ? Section->sh_offset - Section->sh_addr : 0); return object_error::success; default: Result = UnknownAddressOrSize; @@ -502,28 +505,25 @@ const Elf_Sym *symb = getSymbol(Symb); const Elf_Shdr *Section; switch (getSymbolTableIndex(symb)) { - case ELF::SHN_COMMON: // Fall through. + case ELF::SHN_COMMON: // Undefined symbols have no address yet. case ELF::SHN_UNDEF: Result = UnknownAddressOrSize; return object_error::success; case ELF::SHN_ABS: - Result = reinterpret_cast(base()+symb->st_value); + Result = symb->st_value; return object_error::success; default: Section = getSection(symb); } - const uint8_t* addr = base(); - if (Section) - addr += Section->sh_offset; + switch (symb->getType()) { case ELF::STT_SECTION: - Result = reinterpret_cast(addr); + Result = Section ? Section->sh_addr : UnknownAddressOrSize; return object_error::success; - case ELF::STT_FUNC: // Fall through. - case ELF::STT_OBJECT: // Fall through. + case ELF::STT_FUNC: + case ELF::STT_OBJECT: case ELF::STT_NOTYPE: - addr += symb->st_value; - Result = reinterpret_cast(addr); + Result = symb->st_value; return object_error::success; default: Result = UnknownAddressOrSize; @@ -922,6 +922,29 @@ template error_code ELFObjectFile + ::getRelocationOffset(DataRefImpl Rel, + uint64_t &Result) const { + uint64_t offset; + const Elf_Shdr *sec = getSection(Rel.w.b); + switch (sec->sh_type) { + default : + report_fatal_error("Invalid section type in Rel!"); + case ELF::SHT_REL : { + offset = getRel(Rel)->r_offset; + break; + } + case ELF::SHT_RELA : { + offset = getRela(Rel)->r_offset; + break; + } + } + + Result = offset - sec->sh_addr; + return object_error::success; +} + +template +error_code ELFObjectFile ::getRelocationType(DataRefImpl Rel, uint64_t &Result) const { const Elf_Shdr *sec = getSection(Rel.w.b); Modified: llvm/trunk/lib/Object/MachOObjectFile.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Object/MachOObjectFile.cpp?rev=145180&r1=145179&r2=145180&view=diff ============================================================================== --- llvm/trunk/lib/Object/MachOObjectFile.cpp (original) +++ llvm/trunk/lib/Object/MachOObjectFile.cpp Sun Nov 27 04:12:52 2011 @@ -125,23 +125,27 @@ return object_error::success; } -error_code MachOObjectFile::getSymbolOffset(DataRefImpl DRI, - uint64_t &Result) const { - uint64_t SectionOffset; - uint8_t SectionIndex; +error_code MachOObjectFile::getSymbolFileOffset(DataRefImpl DRI, + uint64_t &Result) const { if (MachOObj->is64Bit()) { InMemoryStruct Entry; getSymbol64TableEntry(DRI, Entry); Result = Entry->Value; - SectionIndex = Entry->SectionIndex; + if (Entry->SectionIndex) { + InMemoryStruct Section; + getSection64(Sections[Entry->SectionIndex-1], Section); + Result += Section->Offset - Section->Address; + } } else { InMemoryStruct Entry; getSymbolTableEntry(DRI, Entry); Result = Entry->Value; - SectionIndex = Entry->SectionIndex; + if (Entry->SectionIndex) { + InMemoryStruct Section; + getSection(Sections[Entry->SectionIndex-1], Section); + Result += Section->Offset - Section->Address; + } } - getSectionAddress(Sections[SectionIndex-1], SectionOffset); - Result -= SectionOffset; return object_error::success; } @@ -162,7 +166,50 @@ error_code MachOObjectFile::getSymbolSize(DataRefImpl DRI, uint64_t &Result) const { - Result = UnknownAddressOrSize; + uint32_t LoadCommandCount = MachOObj->getHeader().NumLoadCommands; + uint64_t BeginOffset; + uint64_t EndOffset = 0; + uint8_t SectionIndex; + if (MachOObj->is64Bit()) { + InMemoryStruct Entry; + getSymbol64TableEntry(DRI, Entry); + BeginOffset = Entry->Value; + SectionIndex = Entry->SectionIndex; + if (!SectionIndex) { + Result = UnknownAddressOrSize; + return object_error::success; + } + DRI.d.b++; + moveToNextSymbol(DRI); + if (DRI.d.a < LoadCommandCount) { + getSymbol64TableEntry(DRI, Entry); + if (Entry->SectionIndex == SectionIndex) + EndOffset += Entry->Value; + } + } else { + InMemoryStruct Entry; + getSymbolTableEntry(DRI, Entry); + BeginOffset = Entry->Value; + SectionIndex = Entry->SectionIndex; + if (!SectionIndex) { + Result = UnknownAddressOrSize; + return object_error::success; + } + DRI.d.b++; + moveToNextSymbol(DRI); + if (DRI.d.a < LoadCommandCount) { + getSymbolTableEntry(DRI, Entry); + if (Entry->SectionIndex == SectionIndex) + EndOffset += Entry->Value; + } + } + if (!EndOffset) { + uint64_t Size; + getSectionSize(Sections[SectionIndex-1], Size); + getSectionAddress(Sections[SectionIndex-1], EndOffset); + EndOffset += Size; + } + Result = EndOffset - BeginOffset; return object_error::success; } @@ -275,7 +322,7 @@ if (index == 0) Res = end_sections(); else - Res = section_iterator(SectionRef(Sections[index], this)); + Res = section_iterator(SectionRef(Sections[index-1], this)); return object_error::success; } @@ -614,7 +661,7 @@ bool isScattered = (Arch != Triple::x86_64) && (RE->Word0 & macho::RF_Scattered); uint64_t RelAddr = 0; - if (isScattered) + if (isScattered) RelAddr = RE->Word0 & 0xFFFFFF; else RelAddr = RE->Word0; @@ -622,6 +669,20 @@ Res = reinterpret_cast(sectAddress + RelAddr); return object_error::success; } +error_code MachOObjectFile::getRelocationOffset(DataRefImpl Rel, + uint64_t &Res) const { + InMemoryStruct RE; + getRelocation(Rel, RE); + + unsigned Arch = getArch(); + bool isScattered = (Arch != Triple::x86_64) && + (RE->Word0 & macho::RF_Scattered); + if (isScattered) + Res = RE->Word0 & 0xFFFFFF; + else + Res = RE->Word0; + return object_error::success; +} error_code MachOObjectFile::getRelocationSymbol(DataRefImpl Rel, SymbolRef &Res) const { InMemoryStruct RE; Modified: llvm/trunk/lib/Object/Object.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Object/Object.cpp?rev=145180&r1=145179&r2=145180&view=diff ============================================================================== --- llvm/trunk/lib/Object/Object.cpp (original) +++ llvm/trunk/lib/Object/Object.cpp Sun Nov 27 04:12:52 2011 @@ -150,9 +150,9 @@ return ret; } -uint64_t LLVMGetSymbolOffset(LLVMSymbolIteratorRef SI) { +uint64_t LLVMGetSymbolFileOffset(LLVMSymbolIteratorRef SI) { uint64_t ret; - if (error_code ec = (*unwrap(SI))->getOffset(ret)) + if (error_code ec = (*unwrap(SI))->getFileOffset(ret)) report_fatal_error(ec.message()); return ret; } @@ -172,6 +172,13 @@ return ret; } +uint64_t LLVMGetRelocationOffset(LLVMRelocationIteratorRef RI) { + uint64_t ret; + if (error_code ec = (*unwrap(RI))->getOffset(ret)) + report_fatal_error(ec.message()); + return ret; +} + LLVMSymbolIteratorRef LLVMGetRelocationSymbol(LLVMRelocationIteratorRef RI) { SymbolRef ret; if (error_code ec = (*unwrap(RI))->getSymbol(ret)) Modified: llvm/trunk/tools/llvm-nm/llvm-nm.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvm-nm/llvm-nm.cpp?rev=145180&r1=145179&r2=145180&view=diff ============================================================================== --- llvm/trunk/tools/llvm-nm/llvm-nm.cpp (original) +++ llvm/trunk/tools/llvm-nm/llvm-nm.cpp Sun Nov 27 04:12:52 2011 @@ -286,7 +286,7 @@ if (error(i->getSize(s.Size))) break; } if (PrintAddress) - if (error(i->getOffset(s.Address))) break; + if (error(i->getFileOffset(s.Address))) break; if (error(i->getNMTypeChar(s.TypeChar))) break; if (error(i->getName(s.Name))) break; SymbolList.push_back(s); Modified: llvm/trunk/tools/llvm-objdump/MachODump.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvm-objdump/MachODump.cpp?rev=145180&r1=145179&r2=145180&view=diff ============================================================================== --- llvm/trunk/tools/llvm-objdump/MachODump.cpp (original) +++ llvm/trunk/tools/llvm-objdump/MachODump.cpp Sun Nov 27 04:12:52 2011 @@ -419,7 +419,7 @@ // Start at the address of the symbol relative to the section's address. uint64_t Start = 0; - Symbols[SymIdx].getOffset(Start); + Symbols[SymIdx].getFileOffset(Start); // Stop disassembling either at the beginning of the next symbol or at // the end of the section. @@ -432,7 +432,7 @@ if (NextSymType == SymbolRef::ST_Function) { Sections[SectIdx].containsSymbol(Symbols[NextSymIdx], containsNextSym); - Symbols[NextSymIdx].getOffset(NextSym); + Symbols[NextSymIdx].getFileOffset(NextSym); break; } ++NextSymIdx; Modified: llvm/trunk/tools/llvm-objdump/llvm-objdump.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvm-objdump/llvm-objdump.cpp?rev=145180&r1=145179&r2=145180&view=diff ============================================================================== --- llvm/trunk/tools/llvm-objdump/llvm-objdump.cpp (original) +++ llvm/trunk/tools/llvm-objdump/llvm-objdump.cpp Sun Nov 27 04:12:52 2011 @@ -186,7 +186,7 @@ bool contains; if (!error(i->containsSymbol(*si, contains)) && contains) { uint64_t Address; - if (error(si->getOffset(Address))) break; + if (error(si->getFileOffset(Address))) break; StringRef Name; if (error(si->getName(Name))) break; Symbols.push_back(std::make_pair(Address, Name)); @@ -485,7 +485,7 @@ uint64_t Size; section_iterator Section = o->end_sections(); if (error(si->getName(Name))) continue; - if (error(si->getOffset(Offset))) continue; + if (error(si->getFileOffset(Offset))) continue; if (error(si->isGlobal(Global))) continue; if (error(si->getType(Type))) continue; if (error(si->isWeak(Weak))) continue; From dmalyshev at accesssoftek.com Sun Nov 27 04:19:06 2011 From: dmalyshev at accesssoftek.com (Danil Malyshev) Date: Sun, 27 Nov 2011 02:19:06 -0800 Subject: [llvm-commits] MachOObjectFile fix functions In-Reply-To: References: <6AE1604EE3EC5F4296C096518C6B77EE1805B07349@mail.accesssoftek.com> <6AE1604EE3EC5F4296C096518C6B77EE1805C8FA97@mail.accesssoftek.com> <6AE1604EE3EC5F4296C096518C6B77EE18123D6BC3@mail.accesssoftek.com> <6AE1604EE3EC5F4296C096518C6B77EE1AA49B09EF@mail.accesssoftek.com> Message-ID: <6AE1604EE3EC5F4296C096518C6B77EE1AA49B0A09@mail.accesssoftek.com> Hello, Committed as 145180, thank you! Regards, Danil ________________________________ From: Owen Anderson [mailto:resistor at mac.com] Sent: Saturday, November 26, 2011 12:59 AM To: Danil Malyshev Cc: 'llvm-commits at cs.uiuc.edu' Subject: Re: [llvm-commits] MachOObjectFile fix functions Danil, I'm good with this version. Go ahead and apply. --Owen On Nov 24, 2011, at 12:05 PM, Danil Malyshev wrote: ping ________________________________ From: Danil Malyshev Sent: Saturday, November 12, 2011 3:00 AM To: 'Owen Anderson' Cc: 'llvm-commits at cs.uiuc.edu' Subject: RE: [llvm-commits] MachOObjectFile fix functions Hello Owen > I see your reasoning here, but it scares me a little bit to have methods with the same name that do different things. > I think we should either rename them to be obviously different, or pick a consistent meaning for all of them. I have renamed symbol.getOffset() as getFileOffset(). Please find attached the changed patch. Regards, Danil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20111127/03e86e1a/attachment-0001.html From chandlerc at gmail.com Sun Nov 27 04:32:16 2011 From: chandlerc at gmail.com (Chandler Carruth) Date: Sun, 27 Nov 2011 10:32:16 -0000 Subject: [llvm-commits] [llvm] r145181 - /llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp Message-ID: <20111127103216.636B02A6C12D@llvm.org> Author: chandlerc Date: Sun Nov 27 04:32:16 2011 New Revision: 145181 URL: http://llvm.org/viewvc/llvm-project?rev=145181&view=rev Log: Fix an impressive type-o / spell-o Duncan noticed. Modified: llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp Modified: llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp?rev=145181&r1=145180&r2=145181&view=diff ============================================================================== --- llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp (original) +++ llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp Sun Nov 27 04:32:16 2011 @@ -587,7 +587,7 @@ // completely remove a branch. We bail if the analysis fails or we don't find // an unconditional backedge. Note that this has to handle cases where the // original order was rotated, and the chain has un-done it. As a result, - // there may not (yet) be the uncondiationl branch, but we can tell whether + // there may not (yet) be the unconditional branch, but we can tell whether // one will be added when updating the terminators. SmallVector Cond; MachineBasicBlock *TBB = 0, *FBB = 0; From chandlerc at gmail.com Sun Nov 27 04:37:47 2011 From: chandlerc at gmail.com (Chandler Carruth) Date: Sun, 27 Nov 2011 10:37:47 -0000 Subject: [llvm-commits] [llvm] r145182 - in /llvm/trunk: include/llvm-c/Object.h include/llvm/Object/COFF.h include/llvm/Object/MachO.h include/llvm/Object/ObjectFile.h lib/Object/COFFObjectFile.cpp lib/Object/ELFObjectFile.cpp lib/Object/MachOObjectFile.cpp lib/Object/Object.cpp tools/llvm-nm/llvm-nm.cpp tools/llvm-objdump/MachODump.cpp tools/llvm-objdump/llvm-objdump.cpp Message-ID: <20111127103748.103392A6C12D@llvm.org> Author: chandlerc Date: Sun Nov 27 04:37:47 2011 New Revision: 145182 URL: http://llvm.org/viewvc/llvm-project?rev=145182&view=rev Log: Revert r145180 as it is causing test failures on all the bots. Original commit message: Fixed ObjectFile functions: - getSymbolOffset() renamed as getSymbolFileOffset() - getSymbolFileOffset(), getSymbolAddress(), getRelocationAddress() returns same result for ELFObjectFile, MachOObjectFile and COFFObjectFile. - added getRelocationOffset() - fixed MachOObjectFile::getSymbolSize() - fixed MachOObjectFile::getSymbolSection() - fixed MachOObjectFile::getSymbolOffset() for symbols without section data. Modified: llvm/trunk/include/llvm-c/Object.h llvm/trunk/include/llvm/Object/COFF.h llvm/trunk/include/llvm/Object/MachO.h llvm/trunk/include/llvm/Object/ObjectFile.h llvm/trunk/lib/Object/COFFObjectFile.cpp llvm/trunk/lib/Object/ELFObjectFile.cpp llvm/trunk/lib/Object/MachOObjectFile.cpp llvm/trunk/lib/Object/Object.cpp llvm/trunk/tools/llvm-nm/llvm-nm.cpp llvm/trunk/tools/llvm-objdump/MachODump.cpp llvm/trunk/tools/llvm-objdump/llvm-objdump.cpp Modified: llvm/trunk/include/llvm-c/Object.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm-c/Object.h?rev=145182&r1=145181&r2=145182&view=diff ============================================================================== --- llvm/trunk/include/llvm-c/Object.h (original) +++ llvm/trunk/include/llvm-c/Object.h Sun Nov 27 04:37:47 2011 @@ -73,12 +73,11 @@ // SymbolRef accessors const char *LLVMGetSymbolName(LLVMSymbolIteratorRef SI); uint64_t LLVMGetSymbolAddress(LLVMSymbolIteratorRef SI); -uint64_t LLVMGetSymbolFileOffset(LLVMSymbolIteratorRef SI); +uint64_t LLVMGetSymbolOffset(LLVMSymbolIteratorRef SI); uint64_t LLVMGetSymbolSize(LLVMSymbolIteratorRef SI); // RelocationRef accessors uint64_t LLVMGetRelocationAddress(LLVMRelocationIteratorRef RI); -uint64_t LLVMGetRelocationOffset(LLVMRelocationIteratorRef RI); LLVMSymbolIteratorRef LLVMGetRelocationSymbol(LLVMRelocationIteratorRef RI); uint64_t LLVMGetRelocationType(LLVMRelocationIteratorRef RI); // NOTE: Caller takes ownership of returned string of the two Modified: llvm/trunk/include/llvm/Object/COFF.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Object/COFF.h?rev=145182&r1=145181&r2=145182&view=diff ============================================================================== --- llvm/trunk/include/llvm/Object/COFF.h (original) +++ llvm/trunk/include/llvm/Object/COFF.h Sun Nov 27 04:37:47 2011 @@ -105,7 +105,7 @@ protected: virtual error_code getSymbolNext(DataRefImpl Symb, SymbolRef &Res) const; virtual error_code getSymbolName(DataRefImpl Symb, StringRef &Res) const; - virtual error_code getSymbolFileOffset(DataRefImpl Symb, uint64_t &Res) const; + virtual error_code getSymbolOffset(DataRefImpl Symb, uint64_t &Res) const; virtual error_code getSymbolAddress(DataRefImpl Symb, uint64_t &Res) const; virtual error_code getSymbolSize(DataRefImpl Symb, uint64_t &Res) const; virtual error_code getSymbolNMTypeChar(DataRefImpl Symb, char &Res) const; @@ -135,8 +135,6 @@ RelocationRef &Res) const; virtual error_code getRelocationAddress(DataRefImpl Rel, uint64_t &Res) const; - virtual error_code getRelocationOffset(DataRefImpl Rel, - uint64_t &Res) const; virtual error_code getRelocationSymbol(DataRefImpl Rel, SymbolRef &Res) const; virtual error_code getRelocationType(DataRefImpl Rel, Modified: llvm/trunk/include/llvm/Object/MachO.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Object/MachO.h?rev=145182&r1=145181&r2=145182&view=diff ============================================================================== --- llvm/trunk/include/llvm/Object/MachO.h (original) +++ llvm/trunk/include/llvm/Object/MachO.h Sun Nov 27 04:37:47 2011 @@ -49,7 +49,7 @@ protected: virtual error_code getSymbolNext(DataRefImpl Symb, SymbolRef &Res) const; virtual error_code getSymbolName(DataRefImpl Symb, StringRef &Res) const; - virtual error_code getSymbolFileOffset(DataRefImpl Symb, uint64_t &Res) const; + virtual error_code getSymbolOffset(DataRefImpl Symb, uint64_t &Res) const; virtual error_code getSymbolAddress(DataRefImpl Symb, uint64_t &Res) const; virtual error_code getSymbolSize(DataRefImpl Symb, uint64_t &Res) const; virtual error_code getSymbolNMTypeChar(DataRefImpl Symb, char &Res) const; @@ -79,8 +79,6 @@ RelocationRef &Res) const; virtual error_code getRelocationAddress(DataRefImpl Rel, uint64_t &Res) const; - virtual error_code getRelocationOffset(DataRefImpl Rel, - uint64_t &Res) const; virtual error_code getRelocationSymbol(DataRefImpl Rel, SymbolRef &Res) const; virtual error_code getRelocationType(DataRefImpl Rel, Modified: llvm/trunk/include/llvm/Object/ObjectFile.h URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Object/ObjectFile.h?rev=145182&r1=145181&r2=145182&view=diff ============================================================================== --- llvm/trunk/include/llvm/Object/ObjectFile.h (original) +++ llvm/trunk/include/llvm/Object/ObjectFile.h Sun Nov 27 04:37:47 2011 @@ -104,7 +104,6 @@ error_code getNext(RelocationRef &Result) const; error_code getAddress(uint64_t &Result) const; - error_code getOffset(uint64_t &Result) const; error_code getSymbol(SymbolRef &Result) const; error_code getType(uint64_t &Result) const; @@ -196,7 +195,7 @@ error_code getName(StringRef &Result) const; error_code getAddress(uint64_t &Result) const; - error_code getFileOffset(uint64_t &Result) const; + error_code getOffset(uint64_t &Result) const; error_code getSize(uint64_t &Result) const; error_code getType(SymbolRef::Type &Result) const; @@ -255,7 +254,7 @@ virtual error_code getSymbolNext(DataRefImpl Symb, SymbolRef &Res) const = 0; virtual error_code getSymbolName(DataRefImpl Symb, StringRef &Res) const = 0; virtual error_code getSymbolAddress(DataRefImpl Symb, uint64_t &Res) const =0; - virtual error_code getSymbolFileOffset(DataRefImpl Symb, uint64_t &Res) const =0; + virtual error_code getSymbolOffset(DataRefImpl Symb, uint64_t &Res) const =0; virtual error_code getSymbolSize(DataRefImpl Symb, uint64_t &Res) const = 0; virtual error_code getSymbolType(DataRefImpl Symb, SymbolRef::Type &Res) const = 0; @@ -290,8 +289,6 @@ RelocationRef &Res) const = 0; virtual error_code getRelocationAddress(DataRefImpl Rel, uint64_t &Res) const =0; - virtual error_code getRelocationOffset(DataRefImpl Rel, - uint64_t &Res) const =0; virtual error_code getRelocationSymbol(DataRefImpl Rel, SymbolRef &Res) const = 0; virtual error_code getRelocationType(DataRefImpl Rel, @@ -366,8 +363,8 @@ return OwningObject->getSymbolAddress(SymbolPimpl, Result); } -inline error_code SymbolRef::getFileOffset(uint64_t &Result) const { - return OwningObject->getSymbolFileOffset(SymbolPimpl, Result); +inline error_code SymbolRef::getOffset(uint64_t &Result) const { + return OwningObject->getSymbolOffset(SymbolPimpl, Result); } inline error_code SymbolRef::getSize(uint64_t &Result) const { @@ -489,10 +486,6 @@ return OwningObject->getRelocationAddress(RelocationPimpl, Result); } -inline error_code RelocationRef::getOffset(uint64_t &Result) const { - return OwningObject->getRelocationOffset(RelocationPimpl, Result); -} - inline error_code RelocationRef::getSymbol(SymbolRef &Result) const { return OwningObject->getRelocationSymbol(RelocationPimpl, Result); } Modified: llvm/trunk/lib/Object/COFFObjectFile.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Object/COFFObjectFile.cpp?rev=145182&r1=145181&r2=145182&view=diff ============================================================================== --- llvm/trunk/lib/Object/COFFObjectFile.cpp (original) +++ llvm/trunk/lib/Object/COFFObjectFile.cpp Sun Nov 27 04:37:47 2011 @@ -101,7 +101,7 @@ return getSymbolName(symb, Result); } -error_code COFFObjectFile::getSymbolFileOffset(DataRefImpl Symb, +error_code COFFObjectFile::getSymbolOffset(DataRefImpl Symb, uint64_t &Result) const { const coff_symbol *symb = toSymb(Symb); const coff_section *Section = NULL; @@ -113,7 +113,7 @@ if (Type == 'U' || Type == 'w') Result = UnknownAddressOrSize; else if (Section) - Result = Section->PointerToRawData + symb->Value; + Result = Section->VirtualAddress + symb->Value; else Result = symb->Value; return object_error::success; @@ -131,9 +131,11 @@ if (Type == 'U' || Type == 'w') Result = UnknownAddressOrSize; else if (Section) - Result = Section->VirtualAddress + symb->Value; + Result = reinterpret_cast(base() + + Section->PointerToRawData + + symb->Value); else - Result = symb->Value; + Result = reinterpret_cast(base() + symb->Value); return object_error::success; } @@ -622,11 +624,6 @@ Res = toRel(Rel)->VirtualAddress; return object_error::success; } -error_code COFFObjectFile::getRelocationOffset(DataRefImpl Rel, - uint64_t &Res) const { - Res = toRel(Rel)->VirtualAddress; - return object_error::success; -} error_code COFFObjectFile::getRelocationSymbol(DataRefImpl Rel, SymbolRef &Res) const { const coff_relocation* R = toRel(Rel); Modified: llvm/trunk/lib/Object/ELFObjectFile.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Object/ELFObjectFile.cpp?rev=145182&r1=145181&r2=145182&view=diff ============================================================================== --- llvm/trunk/lib/Object/ELFObjectFile.cpp (original) +++ llvm/trunk/lib/Object/ELFObjectFile.cpp Sun Nov 27 04:37:47 2011 @@ -325,7 +325,7 @@ protected: virtual error_code getSymbolNext(DataRefImpl Symb, SymbolRef &Res) const; virtual error_code getSymbolName(DataRefImpl Symb, StringRef &Res) const; - virtual error_code getSymbolFileOffset(DataRefImpl Symb, uint64_t &Res) const; + virtual error_code getSymbolOffset(DataRefImpl Symb, uint64_t &Res) const; virtual error_code getSymbolAddress(DataRefImpl Symb, uint64_t &Res) const; virtual error_code getSymbolSize(DataRefImpl Symb, uint64_t &Res) const; virtual error_code getSymbolNMTypeChar(DataRefImpl Symb, char &Res) const; @@ -355,8 +355,6 @@ RelocationRef &Res) const; virtual error_code getRelocationAddress(DataRefImpl Rel, uint64_t &Res) const; - virtual error_code getRelocationOffset(DataRefImpl Rel, - uint64_t &Res) const; virtual error_code getRelocationSymbol(DataRefImpl Rel, SymbolRef &Res) const; virtual error_code getRelocationType(DataRefImpl Rel, @@ -464,7 +462,7 @@ template error_code ELFObjectFile - ::getSymbolFileOffset(DataRefImpl Symb, + ::getSymbolOffset(DataRefImpl Symb, uint64_t &Result) const { validateSymbol(Symb); const Elf_Sym *symb = getSymbol(Symb); @@ -488,8 +486,7 @@ case ELF::STT_FUNC: case ELF::STT_OBJECT: case ELF::STT_NOTYPE: - Result = symb->st_value + - (Section ? Section->sh_offset - Section->sh_addr : 0); + Result = symb->st_value; return object_error::success; default: Result = UnknownAddressOrSize; @@ -505,25 +502,28 @@ const Elf_Sym *symb = getSymbol(Symb); const Elf_Shdr *Section; switch (getSymbolTableIndex(symb)) { - case ELF::SHN_COMMON: + case ELF::SHN_COMMON: // Fall through. // Undefined symbols have no address yet. case ELF::SHN_UNDEF: Result = UnknownAddressOrSize; return object_error::success; case ELF::SHN_ABS: - Result = symb->st_value; + Result = reinterpret_cast(base()+symb->st_value); return object_error::success; default: Section = getSection(symb); } - + const uint8_t* addr = base(); + if (Section) + addr += Section->sh_offset; switch (symb->getType()) { case ELF::STT_SECTION: - Result = Section ? Section->sh_addr : UnknownAddressOrSize; + Result = reinterpret_cast(addr); return object_error::success; - case ELF::STT_FUNC: - case ELF::STT_OBJECT: + case ELF::STT_FUNC: // Fall through. + case ELF::STT_OBJECT: // Fall through. case ELF::STT_NOTYPE: - Result = symb->st_value; + addr += symb->st_value; + Result = reinterpret_cast(addr); return object_error::success; default: Result = UnknownAddressOrSize; @@ -922,29 +922,6 @@ template error_code ELFObjectFile - ::getRelocationOffset(DataRefImpl Rel, - uint64_t &Result) const { - uint64_t offset; - const Elf_Shdr *sec = getSection(Rel.w.b); - switch (sec->sh_type) { - default : - report_fatal_error("Invalid section type in Rel!"); - case ELF::SHT_REL : { - offset = getRel(Rel)->r_offset; - break; - } - case ELF::SHT_RELA : { - offset = getRela(Rel)->r_offset; - break; - } - } - - Result = offset - sec->sh_addr; - return object_error::success; -} - -template -error_code ELFObjectFile ::getRelocationType(DataRefImpl Rel, uint64_t &Result) const { const Elf_Shdr *sec = getSection(Rel.w.b); Modified: llvm/trunk/lib/Object/MachOObjectFile.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Object/MachOObjectFile.cpp?rev=145182&r1=145181&r2=145182&view=diff ============================================================================== --- llvm/trunk/lib/Object/MachOObjectFile.cpp (original) +++ llvm/trunk/lib/Object/MachOObjectFile.cpp Sun Nov 27 04:37:47 2011 @@ -125,27 +125,23 @@ return object_error::success; } -error_code MachOObjectFile::getSymbolFileOffset(DataRefImpl DRI, - uint64_t &Result) const { +error_code MachOObjectFile::getSymbolOffset(DataRefImpl DRI, + uint64_t &Result) const { + uint64_t SectionOffset; + uint8_t SectionIndex; if (MachOObj->is64Bit()) { InMemoryStruct Entry; getSymbol64TableEntry(DRI, Entry); Result = Entry->Value; - if (Entry->SectionIndex) { - InMemoryStruct Section; - getSection64(Sections[Entry->SectionIndex-1], Section); - Result += Section->Offset - Section->Address; - } + SectionIndex = Entry->SectionIndex; } else { InMemoryStruct Entry; getSymbolTableEntry(DRI, Entry); Result = Entry->Value; - if (Entry->SectionIndex) { - InMemoryStruct Section; - getSection(Sections[Entry->SectionIndex-1], Section); - Result += Section->Offset - Section->Address; - } + SectionIndex = Entry->SectionIndex; } + getSectionAddress(Sections[SectionIndex-1], SectionOffset); + Result -= SectionOffset; return object_error::success; } @@ -166,50 +162,7 @@ error_code MachOObjectFile::getSymbolSize(DataRefImpl DRI, uint64_t &Result) const { - uint32_t LoadCommandCount = MachOObj->getHeader().NumLoadCommands; - uint64_t BeginOffset; - uint64_t EndOffset = 0; - uint8_t SectionIndex; - if (MachOObj->is64Bit()) { - InMemoryStruct Entry; - getSymbol64TableEntry(DRI, Entry); - BeginOffset = Entry->Value; - SectionIndex = Entry->SectionIndex; - if (!SectionIndex) { - Result = UnknownAddressOrSize; - return object_error::success; - } - DRI.d.b++; - moveToNextSymbol(DRI); - if (DRI.d.a < LoadCommandCount) { - getSymbol64TableEntry(DRI, Entry); - if (Entry->SectionIndex == SectionIndex) - EndOffset += Entry->Value; - } - } else { - InMemoryStruct Entry; - getSymbolTableEntry(DRI, Entry); - BeginOffset = Entry->Value; - SectionIndex = Entry->SectionIndex; - if (!SectionIndex) { - Result = UnknownAddressOrSize; - return object_error::success; - } - DRI.d.b++; - moveToNextSymbol(DRI); - if (DRI.d.a < LoadCommandCount) { - getSymbolTableEntry(DRI, Entry); - if (Entry->SectionIndex == SectionIndex) - EndOffset += Entry->Value; - } - } - if (!EndOffset) { - uint64_t Size; - getSectionSize(Sections[SectionIndex-1], Size); - getSectionAddress(Sections[SectionIndex-1], EndOffset); - EndOffset += Size; - } - Result = EndOffset - BeginOffset; + Result = UnknownAddressOrSize; return object_error::success; } @@ -322,7 +275,7 @@ if (index == 0) Res = end_sections(); else - Res = section_iterator(SectionRef(Sections[index-1], this)); + Res = section_iterator(SectionRef(Sections[index], this)); return object_error::success; } @@ -661,7 +614,7 @@ bool isScattered = (Arch != Triple::x86_64) && (RE->Word0 & macho::RF_Scattered); uint64_t RelAddr = 0; - if (isScattered) + if (isScattered) RelAddr = RE->Word0 & 0xFFFFFF; else RelAddr = RE->Word0; @@ -669,20 +622,6 @@ Res = reinterpret_cast(sectAddress + RelAddr); return object_error::success; } -error_code MachOObjectFile::getRelocationOffset(DataRefImpl Rel, - uint64_t &Res) const { - InMemoryStruct RE; - getRelocation(Rel, RE); - - unsigned Arch = getArch(); - bool isScattered = (Arch != Triple::x86_64) && - (RE->Word0 & macho::RF_Scattered); - if (isScattered) - Res = RE->Word0 & 0xFFFFFF; - else - Res = RE->Word0; - return object_error::success; -} error_code MachOObjectFile::getRelocationSymbol(DataRefImpl Rel, SymbolRef &Res) const { InMemoryStruct RE; Modified: llvm/trunk/lib/Object/Object.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Object/Object.cpp?rev=145182&r1=145181&r2=145182&view=diff ============================================================================== --- llvm/trunk/lib/Object/Object.cpp (original) +++ llvm/trunk/lib/Object/Object.cpp Sun Nov 27 04:37:47 2011 @@ -150,9 +150,9 @@ return ret; } -uint64_t LLVMGetSymbolFileOffset(LLVMSymbolIteratorRef SI) { +uint64_t LLVMGetSymbolOffset(LLVMSymbolIteratorRef SI) { uint64_t ret; - if (error_code ec = (*unwrap(SI))->getFileOffset(ret)) + if (error_code ec = (*unwrap(SI))->getOffset(ret)) report_fatal_error(ec.message()); return ret; } @@ -172,13 +172,6 @@ return ret; } -uint64_t LLVMGetRelocationOffset(LLVMRelocationIteratorRef RI) { - uint64_t ret; - if (error_code ec = (*unwrap(RI))->getOffset(ret)) - report_fatal_error(ec.message()); - return ret; -} - LLVMSymbolIteratorRef LLVMGetRelocationSymbol(LLVMRelocationIteratorRef RI) { SymbolRef ret; if (error_code ec = (*unwrap(RI))->getSymbol(ret)) Modified: llvm/trunk/tools/llvm-nm/llvm-nm.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvm-nm/llvm-nm.cpp?rev=145182&r1=145181&r2=145182&view=diff ============================================================================== --- llvm/trunk/tools/llvm-nm/llvm-nm.cpp (original) +++ llvm/trunk/tools/llvm-nm/llvm-nm.cpp Sun Nov 27 04:37:47 2011 @@ -286,7 +286,7 @@ if (error(i->getSize(s.Size))) break; } if (PrintAddress) - if (error(i->getFileOffset(s.Address))) break; + if (error(i->getOffset(s.Address))) break; if (error(i->getNMTypeChar(s.TypeChar))) break; if (error(i->getName(s.Name))) break; SymbolList.push_back(s); Modified: llvm/trunk/tools/llvm-objdump/MachODump.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvm-objdump/MachODump.cpp?rev=145182&r1=145181&r2=145182&view=diff ============================================================================== --- llvm/trunk/tools/llvm-objdump/MachODump.cpp (original) +++ llvm/trunk/tools/llvm-objdump/MachODump.cpp Sun Nov 27 04:37:47 2011 @@ -419,7 +419,7 @@ // Start at the address of the symbol relative to the section's address. uint64_t Start = 0; - Symbols[SymIdx].getFileOffset(Start); + Symbols[SymIdx].getOffset(Start); // Stop disassembling either at the beginning of the next symbol or at // the end of the section. @@ -432,7 +432,7 @@ if (NextSymType == SymbolRef::ST_Function) { Sections[SectIdx].containsSymbol(Symbols[NextSymIdx], containsNextSym); - Symbols[NextSymIdx].getFileOffset(NextSym); + Symbols[NextSymIdx].getOffset(NextSym); break; } ++NextSymIdx; Modified: llvm/trunk/tools/llvm-objdump/llvm-objdump.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvm-objdump/llvm-objdump.cpp?rev=145182&r1=145181&r2=145182&view=diff ============================================================================== --- llvm/trunk/tools/llvm-objdump/llvm-objdump.cpp (original) +++ llvm/trunk/tools/llvm-objdump/llvm-objdump.cpp Sun Nov 27 04:37:47 2011 @@ -186,7 +186,7 @@ bool contains; if (!error(i->containsSymbol(*si, contains)) && contains) { uint64_t Address; - if (error(si->getFileOffset(Address))) break; + if (error(si->getOffset(Address))) break; StringRef Name; if (error(si->getName(Name))) break; Symbols.push_back(std::make_pair(Address, Name)); @@ -485,7 +485,7 @@ uint64_t Size; section_iterator Section = o->end_sections(); if (error(si->getName(Name))) continue; - if (error(si->getFileOffset(Offset))) continue; + if (error(si->getOffset(Offset))) continue; if (error(si->isGlobal(Global))) continue; if (error(si->getType(Type))) continue; if (error(si->isWeak(Weak))) continue; From chandlerc at google.com Sun Nov 27 04:41:40 2011 From: chandlerc at google.com (Chandler Carruth) Date: Sun, 27 Nov 2011 02:41:40 -0800 Subject: [llvm-commits] [llvm] r145180 - in /llvm/trunk: include/llvm-c/Object.h include/llvm/Object/COFF.h include/llvm/Object/MachO.h include/llvm/Object/ObjectFile.h lib/Object/COFFObjectFile.cpp lib/Object/ELFObjectFile.cpp lib/Object/MachOObjectFile. Message-ID: On Sun, Nov 27, 2011 at 2:12 AM, Danil Malyshev wrote: > Author: danil > Date: Sun Nov 27 04:12:52 2011 > New Revision: 145180 > > URL: http://llvm.org/viewvc/llvm-project?rev=145180&view=rev > Log: > Fixed ObjectFile functions: > - getSymbolOffset() renamed as getSymbolFileOffset() > - getSymbolFileOffset(), getSymbolAddress(), getRelocationAddress() > returns same result for ELFObjectFile, MachOObjectFile and COFFObjectFile. > - added getRelocationOffset() > - fixed MachOObjectFile::getSymbolSize() > - fixed MachOObjectFile::getSymbolSection() > - fixed MachOObjectFile::getSymbolOffset() for symbols without section > data. > Danil, I've reverted this in r145182 because it broke tests on most of our build bots: http://lab.llvm.org:8011/builders/llvm-x86_64-linux/builds/1457 It seems to trigger for all of the platforms, so please run the tests next time before you commit... I notice that you didn't update any test files with the commit... was that intentional? At the least, this needs tests to cover all of the "fixed" things you mention in your commit. I suspect it will also need updates to existing tests. > Modified: > llvm/trunk/include/llvm-c/Object.h > llvm/trunk/include/llvm/Object/COFF.h > llvm/trunk/include/llvm/Object/MachO.h > llvm/trunk/include/llvm/Object/ObjectFile.h > llvm/trunk/lib/Object/COFFObjectFile.cpp > llvm/trunk/lib/Object/ELFObjectFile.cpp > llvm/trunk/lib/Object/MachOObjectFile.cpp > llvm/trunk/lib/Object/Object.cpp > llvm/trunk/tools/llvm-nm/llvm-nm.cpp > llvm/trunk/tools/llvm-objdump/MachODump.cpp > llvm/trunk/tools/llvm-objdump/llvm-objdump.cpp > > Modified: llvm/trunk/include/llvm-c/Object.h > URL: > http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm-c/Object.h?rev=145180&r1=145179&r2=145180&view=diff > > ============================================================================== > --- llvm/trunk/include/llvm-c/Object.h (original) > +++ llvm/trunk/include/llvm-c/Object.h Sun Nov 27 04:12:52 2011 > @@ -73,11 +73,12 @@ > // SymbolRef accessors > const char *LLVMGetSymbolName(LLVMSymbolIteratorRef SI); > uint64_t LLVMGetSymbolAddress(LLVMSymbolIteratorRef SI); > -uint64_t LLVMGetSymbolOffset(LLVMSymbolIteratorRef SI); > +uint64_t LLVMGetSymbolFileOffset(LLVMSymbolIteratorRef SI); > uint64_t LLVMGetSymbolSize(LLVMSymbolIteratorRef SI); > > // RelocationRef accessors > uint64_t LLVMGetRelocationAddress(LLVMRelocationIteratorRef RI); > +uint64_t LLVMGetRelocationOffset(LLVMRelocationIteratorRef RI); > LLVMSymbolIteratorRef LLVMGetRelocationSymbol(LLVMRelocationIteratorRef > RI); > uint64_t LLVMGetRelocationType(LLVMRelocationIteratorRef RI); > // NOTE: Caller takes ownership of returned string of the two > > Modified: llvm/trunk/include/llvm/Object/COFF.h > URL: > http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Object/COFF.h?rev=145180&r1=145179&r2=145180&view=diff > > ============================================================================== > --- llvm/trunk/include/llvm/Object/COFF.h (original) > +++ llvm/trunk/include/llvm/Object/COFF.h Sun Nov 27 04:12:52 2011 > @@ -105,7 +105,7 @@ > protected: > virtual error_code getSymbolNext(DataRefImpl Symb, SymbolRef &Res) const; > virtual error_code getSymbolName(DataRefImpl Symb, StringRef &Res) const; > - virtual error_code getSymbolOffset(DataRefImpl Symb, uint64_t &Res) > const; > + virtual error_code getSymbolFileOffset(DataRefImpl Symb, uint64_t &Res) > const; > virtual error_code getSymbolAddress(DataRefImpl Symb, uint64_t &Res) > const; > virtual error_code getSymbolSize(DataRefImpl Symb, uint64_t &Res) const; > virtual error_code getSymbolNMTypeChar(DataRefImpl Symb, char &Res) > const; > @@ -135,6 +135,8 @@ > RelocationRef &Res) const; > virtual error_code getRelocationAddress(DataRefImpl Rel, > uint64_t &Res) const; > + virtual error_code getRelocationOffset(DataRefImpl Rel, > + uint64_t &Res) const; > virtual error_code getRelocationSymbol(DataRefImpl Rel, > SymbolRef &Res) const; > virtual error_code getRelocationType(DataRefImpl Rel, > > Modified: llvm/trunk/include/llvm/Object/MachO.h > URL: > http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Object/MachO.h?rev=145180&r1=145179&r2=145180&view=diff > > ============================================================================== > --- llvm/trunk/include/llvm/Object/MachO.h (original) > +++ llvm/trunk/include/llvm/Object/MachO.h Sun Nov 27 04:12:52 2011 > @@ -49,7 +49,7 @@ > protected: > virtual error_code getSymbolNext(DataRefImpl Symb, SymbolRef &Res) const; > virtual error_code getSymbolName(DataRefImpl Symb, StringRef &Res) const; > - virtual error_code getSymbolOffset(DataRefImpl Symb, uint64_t &Res) > const; > + virtual error_code getSymbolFileOffset(DataRefImpl Symb, uint64_t &Res) > const; > virtual error_code getSymbolAddress(DataRefImpl Symb, uint64_t &Res) > const; > virtual error_code getSymbolSize(DataRefImpl Symb, uint64_t &Res) const; > virtual error_code getSymbolNMTypeChar(DataRefImpl Symb, char &Res) > const; > @@ -79,6 +79,8 @@ > RelocationRef &Res) const; > virtual error_code getRelocationAddress(DataRefImpl Rel, > uint64_t &Res) const; > + virtual error_code getRelocationOffset(DataRefImpl Rel, > + uint64_t &Res) const; > virtual error_code getRelocationSymbol(DataRefImpl Rel, > SymbolRef &Res) const; > virtual error_code getRelocationType(DataRefImpl Rel, > > Modified: llvm/trunk/include/llvm/Object/ObjectFile.h > URL: > http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Object/ObjectFile.h?rev=145180&r1=145179&r2=145180&view=diff > > ============================================================================== > --- llvm/trunk/include/llvm/Object/ObjectFile.h (original) > +++ llvm/trunk/include/llvm/Object/ObjectFile.h Sun Nov 27 04:12:52 2011 > @@ -104,6 +104,7 @@ > error_code getNext(RelocationRef &Result) const; > > error_code getAddress(uint64_t &Result) const; > + error_code getOffset(uint64_t &Result) const; > error_code getSymbol(SymbolRef &Result) const; > error_code getType(uint64_t &Result) const; > > @@ -195,7 +196,7 @@ > > error_code getName(StringRef &Result) const; > error_code getAddress(uint64_t &Result) const; > - error_code getOffset(uint64_t &Result) const; > + error_code getFileOffset(uint64_t &Result) const; > error_code getSize(uint64_t &Result) const; > error_code getType(SymbolRef::Type &Result) const; > > @@ -254,7 +255,7 @@ > virtual error_code getSymbolNext(DataRefImpl Symb, SymbolRef &Res) const > = 0; > virtual error_code getSymbolName(DataRefImpl Symb, StringRef &Res) const > = 0; > virtual error_code getSymbolAddress(DataRefImpl Symb, uint64_t &Res) > const =0; > - virtual error_code getSymbolOffset(DataRefImpl Symb, uint64_t &Res) > const =0; > + virtual error_code getSymbolFileOffset(DataRefImpl Symb, uint64_t &Res) > const =0; > virtual error_code getSymbolSize(DataRefImpl Symb, uint64_t &Res) const > = 0; > virtual error_code getSymbolType(DataRefImpl Symb, > SymbolRef::Type &Res) const = 0; > @@ -289,6 +290,8 @@ > RelocationRef &Res) const = 0; > virtual error_code getRelocationAddress(DataRefImpl Rel, > uint64_t &Res) const =0; > + virtual error_code getRelocationOffset(DataRefImpl Rel, > + uint64_t &Res) const =0; > virtual error_code getRelocationSymbol(DataRefImpl Rel, > SymbolRef &Res) const = 0; > virtual error_code getRelocationType(DataRefImpl Rel, > @@ -363,8 +366,8 @@ > return OwningObject->getSymbolAddress(SymbolPimpl, Result); > } > > -inline error_code SymbolRef::getOffset(uint64_t &Result) const { > - return OwningObject->getSymbolOffset(SymbolPimpl, Result); > +inline error_code SymbolRef::getFileOffset(uint64_t &Result) const { > + return OwningObject->getSymbolFileOffset(SymbolPimpl, Result); > } > > inline error_code SymbolRef::getSize(uint64_t &Result) const { > @@ -486,6 +489,10 @@ > return OwningObject->getRelocationAddress(RelocationPimpl, Result); > } > > +inline error_code RelocationRef::getOffset(uint64_t &Result) const { > + return OwningObject->getRelocationOffset(RelocationPimpl, Result); > +} > + > inline error_code RelocationRef::getSymbol(SymbolRef &Result) const { > return OwningObject->getRelocationSymbol(RelocationPimpl, Result); > } > > Modified: llvm/trunk/lib/Object/COFFObjectFile.cpp > URL: > http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Object/COFFObjectFile.cpp?rev=145180&r1=145179&r2=145180&view=diff > > ============================================================================== > --- llvm/trunk/lib/Object/COFFObjectFile.cpp (original) > +++ llvm/trunk/lib/Object/COFFObjectFile.cpp Sun Nov 27 04:12:52 2011 > @@ -101,7 +101,7 @@ > return getSymbolName(symb, Result); > } > > -error_code COFFObjectFile::getSymbolOffset(DataRefImpl Symb, > +error_code COFFObjectFile::getSymbolFileOffset(DataRefImpl Symb, > uint64_t &Result) const { > const coff_symbol *symb = toSymb(Symb); > const coff_section *Section = NULL; > @@ -113,7 +113,7 @@ > if (Type == 'U' || Type == 'w') > Result = UnknownAddressOrSize; > else if (Section) > - Result = Section->VirtualAddress + symb->Value; > + Result = Section->PointerToRawData + symb->Value; > else > Result = symb->Value; > return object_error::success; > @@ -131,11 +131,9 @@ > if (Type == 'U' || Type == 'w') > Result = UnknownAddressOrSize; > else if (Section) > - Result = reinterpret_cast(base() + > - Section->PointerToRawData + > - symb->Value); > + Result = Section->VirtualAddress + symb->Value; > else > - Result = reinterpret_cast(base() + symb->Value); > + Result = symb->Value; > return object_error::success; > } > > @@ -624,6 +622,11 @@ > Res = toRel(Rel)->VirtualAddress; > return object_error::success; > } > +error_code COFFObjectFile::getRelocationOffset(DataRefImpl Rel, > + uint64_t &Res) const { > + Res = toRel(Rel)->VirtualAddress; > + return object_error::success; > +} > error_code COFFObjectFile::getRelocationSymbol(DataRefImpl Rel, > SymbolRef &Res) const { > const coff_relocation* R = toRel(Rel); > > Modified: llvm/trunk/lib/Object/ELFObjectFile.cpp > URL: > http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Object/ELFObjectFile.cpp?rev=145180&r1=145179&r2=145180&view=diff > > ============================================================================== > --- llvm/trunk/lib/Object/ELFObjectFile.cpp (original) > +++ llvm/trunk/lib/Object/ELFObjectFile.cpp Sun Nov 27 04:12:52 2011 > @@ -325,7 +325,7 @@ > protected: > virtual error_code getSymbolNext(DataRefImpl Symb, SymbolRef &Res) const; > virtual error_code getSymbolName(DataRefImpl Symb, StringRef &Res) const; > - virtual error_code getSymbolOffset(DataRefImpl Symb, uint64_t &Res) > const; > + virtual error_code getSymbolFileOffset(DataRefImpl Symb, uint64_t &Res) > const; > virtual error_code getSymbolAddress(DataRefImpl Symb, uint64_t &Res) > const; > virtual error_code getSymbolSize(DataRefImpl Symb, uint64_t &Res) const; > virtual error_code getSymbolNMTypeChar(DataRefImpl Symb, char &Res) > const; > @@ -355,6 +355,8 @@ > RelocationRef &Res) const; > virtual error_code getRelocationAddress(DataRefImpl Rel, > uint64_t &Res) const; > + virtual error_code getRelocationOffset(DataRefImpl Rel, > + uint64_t &Res) const; > virtual error_code getRelocationSymbol(DataRefImpl Rel, > SymbolRef &Res) const; > virtual error_code getRelocationType(DataRefImpl Rel, > @@ -462,7 +464,7 @@ > > template > error_code ELFObjectFile > - ::getSymbolOffset(DataRefImpl Symb, > + ::getSymbolFileOffset(DataRefImpl Symb, > uint64_t &Result) const { > validateSymbol(Symb); > const Elf_Sym *symb = getSymbol(Symb); > @@ -486,7 +488,8 @@ > case ELF::STT_FUNC: > case ELF::STT_OBJECT: > case ELF::STT_NOTYPE: > - Result = symb->st_value; > + Result = symb->st_value + > + (Section ? Section->sh_offset - Section->sh_addr : 0); > return object_error::success; > default: > Result = UnknownAddressOrSize; > @@ -502,28 +505,25 @@ > const Elf_Sym *symb = getSymbol(Symb); > const Elf_Shdr *Section; > switch (getSymbolTableIndex(symb)) { > - case ELF::SHN_COMMON: // Fall through. > + case ELF::SHN_COMMON: > // Undefined symbols have no address yet. > case ELF::SHN_UNDEF: > Result = UnknownAddressOrSize; > return object_error::success; > case ELF::SHN_ABS: > - Result = reinterpret_cast(base()+symb->st_value); > + Result = symb->st_value; > return object_error::success; > default: Section = getSection(symb); > } > - const uint8_t* addr = base(); > - if (Section) > - addr += Section->sh_offset; > + > switch (symb->getType()) { > case ELF::STT_SECTION: > - Result = reinterpret_cast(addr); > + Result = Section ? Section->sh_addr : UnknownAddressOrSize; > return object_error::success; > - case ELF::STT_FUNC: // Fall through. > - case ELF::STT_OBJECT: // Fall through. > + case ELF::STT_FUNC: > + case ELF::STT_OBJECT: > case ELF::STT_NOTYPE: > - addr += symb->st_value; > - Result = reinterpret_cast(addr); > + Result = symb->st_value; > return object_error::success; > default: > Result = UnknownAddressOrSize; > @@ -922,6 +922,29 @@ > > template > error_code ELFObjectFile > + ::getRelocationOffset(DataRefImpl Rel, > + uint64_t &Result) const { > + uint64_t offset; > + const Elf_Shdr *sec = getSection(Rel.w.b); > + switch (sec->sh_type) { > + default : > + report_fatal_error("Invalid section type in Rel!"); > + case ELF::SHT_REL : { > + offset = getRel(Rel)->r_offset; > + break; > + } > + case ELF::SHT_RELA : { > + offset = getRela(Rel)->r_offset; > + break; > + } > + } > + > + Result = offset - sec->sh_addr; > + return object_error::success; > +} > + > +template > +error_code ELFObjectFile > ::getRelocationType(DataRefImpl Rel, > uint64_t &Result) const { > const Elf_Shdr *sec = getSection(Rel.w.b); > > Modified: llvm/trunk/lib/Object/MachOObjectFile.cpp > URL: > http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Object/MachOObjectFile.cpp?rev=145180&r1=145179&r2=145180&view=diff > > ============================================================================== > --- llvm/trunk/lib/Object/MachOObjectFile.cpp (original) > +++ llvm/trunk/lib/Object/MachOObjectFile.cpp Sun Nov 27 04:12:52 2011 > @@ -125,23 +125,27 @@ > return object_error::success; > } > > -error_code MachOObjectFile::getSymbolOffset(DataRefImpl DRI, > - uint64_t &Result) const { > - uint64_t SectionOffset; > - uint8_t SectionIndex; > +error_code MachOObjectFile::getSymbolFileOffset(DataRefImpl DRI, > + uint64_t &Result) const { > if (MachOObj->is64Bit()) { > InMemoryStruct Entry; > getSymbol64TableEntry(DRI, Entry); > Result = Entry->Value; > - SectionIndex = Entry->SectionIndex; > + if (Entry->SectionIndex) { > + InMemoryStruct Section; > + getSection64(Sections[Entry->SectionIndex-1], Section); > + Result += Section->Offset - Section->Address; > + } > } else { > InMemoryStruct Entry; > getSymbolTableEntry(DRI, Entry); > Result = Entry->Value; > - SectionIndex = Entry->SectionIndex; > + if (Entry->SectionIndex) { > + InMemoryStruct Section; > + getSection(Sections[Entry->SectionIndex-1], Section); > + Result += Section->Offset - Section->Address; > + } > } > - getSectionAddress(Sections[SectionIndex-1], SectionOffset); > - Result -= SectionOffset; > > return object_error::success; > } > @@ -162,7 +166,50 @@ > > error_code MachOObjectFile::getSymbolSize(DataRefImpl DRI, > uint64_t &Result) const { > - Result = UnknownAddressOrSize; > + uint32_t LoadCommandCount = MachOObj->getHeader().NumLoadCommands; > + uint64_t BeginOffset; > + uint64_t EndOffset = 0; > + uint8_t SectionIndex; > + if (MachOObj->is64Bit()) { > + InMemoryStruct Entry; > + getSymbol64TableEntry(DRI, Entry); > + BeginOffset = Entry->Value; > + SectionIndex = Entry->SectionIndex; > + if (!SectionIndex) { > + Result = UnknownAddressOrSize; > + return object_error::success; > + } > + DRI.d.b++; > + moveToNextSymbol(DRI); > + if (DRI.d.a < LoadCommandCount) { > + getSymbol64TableEntry(DRI, Entry); > + if (Entry->SectionIndex == SectionIndex) > + EndOffset += Entry->Value; > + } > + } else { > + InMemoryStruct Entry; > + getSymbolTableEntry(DRI, Entry); > + BeginOffset = Entry->Value; > + SectionIndex = Entry->SectionIndex; > + if (!SectionIndex) { > + Result = UnknownAddressOrSize; > + return object_error::success; > + } > + DRI.d.b++; > + moveToNextSymbol(DRI); > + if (DRI.d.a < LoadCommandCount) { > + getSymbolTableEntry(DRI, Entry); > + if (Entry->SectionIndex == SectionIndex) > + EndOffset += Entry->Value; > + } > + } > + if (!EndOffset) { > + uint64_t Size; > + getSectionSize(Sections[SectionIndex-1], Size); > + getSectionAddress(Sections[SectionIndex-1], EndOffset); > + EndOffset += Size; > + } > + Result = EndOffset - BeginOffset; > return object_error::success; > } > > @@ -275,7 +322,7 @@ > if (index == 0) > Res = end_sections(); > else > - Res = section_iterator(SectionRef(Sections[index], this)); > + Res = section_iterator(SectionRef(Sections[index-1], this)); > > return object_error::success; > } > @@ -614,7 +661,7 @@ > bool isScattered = (Arch != Triple::x86_64) && > (RE->Word0 & macho::RF_Scattered); > uint64_t RelAddr = 0; > - if (isScattered) > + if (isScattered) > RelAddr = RE->Word0 & 0xFFFFFF; > else > RelAddr = RE->Word0; > @@ -622,6 +669,20 @@ > Res = reinterpret_cast(sectAddress + RelAddr); > return object_error::success; > } > +error_code MachOObjectFile::getRelocationOffset(DataRefImpl Rel, > + uint64_t &Res) const { > + InMemoryStruct RE; > + getRelocation(Rel, RE); > + > + unsigned Arch = getArch(); > + bool isScattered = (Arch != Triple::x86_64) && > + (RE->Word0 & macho::RF_Scattered); > + if (isScattered) > + Res = RE->Word0 & 0xFFFFFF; > + else > + Res = RE->Word0; > + return object_error::success; > +} > error_code MachOObjectFile::getRelocationSymbol(DataRefImpl Rel, > SymbolRef &Res) const { > InMemoryStruct RE; > > Modified: llvm/trunk/lib/Object/Object.cpp > URL: > http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Object/Object.cpp?rev=145180&r1=145179&r2=145180&view=diff > > ============================================================================== > --- llvm/trunk/lib/Object/Object.cpp (original) > +++ llvm/trunk/lib/Object/Object.cpp Sun Nov 27 04:12:52 2011 > @@ -150,9 +150,9 @@ > return ret; > } > > -uint64_t LLVMGetSymbolOffset(LLVMSymbolIteratorRef SI) { > +uint64_t LLVMGetSymbolFileOffset(LLVMSymbolIteratorRef SI) { > uint64_t ret; > - if (error_code ec = (*unwrap(SI))->getOffset(ret)) > + if (error_code ec = (*unwrap(SI))->getFileOffset(ret)) > report_fatal_error(ec.message()); > return ret; > } > @@ -172,6 +172,13 @@ > return ret; > } > > +uint64_t LLVMGetRelocationOffset(LLVMRelocationIteratorRef RI) { > + uint64_t ret; > + if (error_code ec = (*unwrap(RI))->getOffset(ret)) > + report_fatal_error(ec.message()); > + return ret; > +} > + > LLVMSymbolIteratorRef LLVMGetRelocationSymbol(LLVMRelocationIteratorRef > RI) { > SymbolRef ret; > if (error_code ec = (*unwrap(RI))->getSymbol(ret)) > > Modified: llvm/trunk/tools/llvm-nm/llvm-nm.cpp > URL: > http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvm-nm/llvm-nm.cpp?rev=145180&r1=145179&r2=145180&view=diff > > ============================================================================== > --- llvm/trunk/tools/llvm-nm/llvm-nm.cpp (original) > +++ llvm/trunk/tools/llvm-nm/llvm-nm.cpp Sun Nov 27 04:12:52 2011 > @@ -286,7 +286,7 @@ > if (error(i->getSize(s.Size))) break; > } > if (PrintAddress) > - if (error(i->getOffset(s.Address))) break; > + if (error(i->getFileOffset(s.Address))) break; > if (error(i->getNMTypeChar(s.TypeChar))) break; > if (error(i->getName(s.Name))) break; > SymbolList.push_back(s); > > Modified: llvm/trunk/tools/llvm-objdump/MachODump.cpp > URL: > http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvm-objdump/MachODump.cpp?rev=145180&r1=145179&r2=145180&view=diff > > ============================================================================== > --- llvm/trunk/tools/llvm-objdump/MachODump.cpp (original) > +++ llvm/trunk/tools/llvm-objdump/MachODump.cpp Sun Nov 27 04:12:52 2011 > @@ -419,7 +419,7 @@ > > // Start at the address of the symbol relative to the section's > address. > uint64_t Start = 0; > - Symbols[SymIdx].getOffset(Start); > + Symbols[SymIdx].getFileOffset(Start); > > // Stop disassembling either at the beginning of the next symbol or > at > // the end of the section. > @@ -432,7 +432,7 @@ > if (NextSymType == SymbolRef::ST_Function) { > Sections[SectIdx].containsSymbol(Symbols[NextSymIdx], > containsNextSym); > - Symbols[NextSymIdx].getOffset(NextSym); > + Symbols[NextSymIdx].getFileOffset(NextSym); > break; > } > ++NextSymIdx; > > Modified: llvm/trunk/tools/llvm-objdump/llvm-objdump.cpp > URL: > http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvm-objdump/llvm-objdump.cpp?rev=145180&r1=145179&r2=145180&view=diff > > ============================================================================== > --- llvm/trunk/tools/llvm-objdump/llvm-objdump.cpp (original) > +++ llvm/trunk/tools/llvm-objdump/llvm-objdump.cpp Sun Nov 27 04:12:52 2011 > @@ -186,7 +186,7 @@ > bool contains; > if (!error(i->containsSymbol(*si, contains)) && contains) { > uint64_t Address; > - if (error(si->getOffset(Address))) break; > + if (error(si->getFileOffset(Address))) break; > StringRef Name; > if (error(si->getName(Name))) break; > Symbols.push_back(std::make_pair(Address, Name)); > @@ -485,7 +485,7 @@ > uint64_t Size; > section_iterator Section = o->end_sections(); > if (error(si->getName(Name))) continue; > - if (error(si->getOffset(Offset))) continue; > + if (error(si->getFileOffset(Offset))) continue; > if (error(si->isGlobal(Global))) continue; > if (error(si->getType(Type))) continue; > if (error(si->isWeak(Weak))) continue; > > > _______________________________________________ > llvm-commits mailing list > llvm-commits at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20111127/985063a3/attachment.html From chandlerc at gmail.com Sun Nov 27 07:34:34 2011 From: chandlerc at gmail.com (Chandler Carruth) Date: Sun, 27 Nov 2011 13:34:34 -0000 Subject: [llvm-commits] [llvm] r145183 - in /llvm/trunk: lib/CodeGen/MachineBlockPlacement.cpp test/CodeGen/X86/block-placement.ll Message-ID: <20111127133434.296CF2A6C12D@llvm.org> Author: chandlerc Date: Sun Nov 27 07:34:33 2011 New Revision: 145183 URL: http://llvm.org/viewvc/llvm-project?rev=145183&view=rev Log: Take two on rotating the block ordering of loops. My previous attempt was centered around the premise of laying out a loop in a chain, and then rotating that chain. This is good for preserving contiguous layout, but bad for actually making sane rotations. In order to keep it safe, I had to essentially make it impossible to rotate deeply nested loops. The information needed to correctly reason about a deeply nested loop is actually available -- *before* we layout the loop. We know the inner loops are already fused into chains, etc. We lose information the moment we actually lay out the loop. The solution was the other alternative for this algorithm I discussed with Benjamin and some others: rather than rotating the loop after-the-fact, try to pick a profitable starting block for the loop's layout, and then use our existing layout logic. I was worried about the complexity of this "pick" step, but it turns out such complexity is needed to handle all the important cases I keep teasing out of benchmarks. This is, I'm afraid, a bit of a work-in-progress. It is still misbehaving on some likely important cases I'm investigating in Olden. It also isn't really tested. I'm going to try to craft some interesting nested-loop test cases, but it's likely to be extremely time consuming and I don't want to go there until I'm sure I'm testing the correct behavior. Sadly I can't come up with a way of getting simple, fine grained test cases for this logic. We need complex loop structures to even trigger much of it. Modified: llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp llvm/trunk/test/CodeGen/X86/block-placement.ll Modified: llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp?rev=145183&r1=145182&r2=145183&view=diff ============================================================================== --- llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp (original) +++ llvm/trunk/lib/CodeGen/MachineBlockPlacement.cpp Sun Nov 27 07:34:33 2011 @@ -226,8 +226,9 @@ void buildChain(MachineBasicBlock *BB, BlockChain &Chain, SmallVectorImpl &BlockWorkList, const BlockFilterSet *BlockFilter = 0); - void rotateLoop(MachineLoop &L, BlockChain &LoopChain, - const BlockFilterSet &LoopBlockSet); + MachineBasicBlock *findBestLoopTop(MachineFunction &F, + MachineLoop &L, + const BlockFilterSet &LoopBlockSet); void buildLoopChains(MachineFunction &F, MachineLoop &L); void buildCFGChains(MachineFunction &F); void AlignLoops(MachineFunction &F); @@ -558,96 +559,110 @@ << getBlockNum(*Chain.begin()) << "\n"); } -/// \brief Attempt to rotate loop chains ending in an unconditional backedge. +/// \brief Find the best loop top block for layout. /// -/// This is a very conservative attempt to rotate unconditional backedge jumps -/// into fallthrough opportunities. It only attempts to perform the rotation -/// when it is trivial to find a block within the loop which has a conditional -/// loop exit. This block is then made the bottom of the chain, and the in-loop -/// fallthrough block the top. That turns a conditional branch out of the loop -/// into a conditional branch to the top of the loop while completely -/// eliminitating an unconditional branch within the loop. -void MachineBlockPlacement::rotateLoop(MachineLoop &L, - BlockChain &LoopChain, +/// This routine implements the logic to analyze the loop looking for the best +/// block to layout at the top of the loop. Typically this is done to maximize +/// fallthrough opportunities. +MachineBasicBlock * +MachineBlockPlacement::findBestLoopTop(MachineFunction &F, + MachineLoop &L, const BlockFilterSet &LoopBlockSet) { - MachineBasicBlock *Header = *L.block_begin(); - // Ensure that we have a chain of blocks which starts with the loop header. - // Otherwise, rotating the blocks might break an analyzable branch. - if (Header != *LoopChain.begin()) - return; + BlockFrequency BestExitEdgeFreq; + MachineBasicBlock *ExitingBB = 0; + MachineBasicBlock *LoopingBB = 0; + DEBUG(dbgs() << "Finding best loop exit for: " + << getBlockName(L.getHeader()) << "\n"); + for (MachineLoop::block_iterator I = L.block_begin(), + E = L.block_end(); + I != E; ++I) { + BlockChain &Chain = *BlockToChain[*I]; + // Ensure that this block is at the end of a chain; otherwise it could be + // mid-way through an inner loop or a successor of an analyzable branch. + if (*I != *llvm::prior(Chain.end())) + continue; + + // Now walk the successors. We need to establish whether this has a viable + // exiting successor and whether it has a viable non-exiting successor. + // We store the old exiting state and restore it if a viable looping + // successor isn't found. + MachineBasicBlock *OldExitingBB = ExitingBB; + BlockFrequency OldBestExitEdgeFreq = BestExitEdgeFreq; + // We also compute and store the best looping successor for use in layout. + MachineBasicBlock *BestLoopSucc = 0; + // FIXME: Due to the performance of the probability and weight routines in + // the MBPI analysis, we use the internal weights. This is only valid + // because it is purely a ranking function, we don't care about anything + // but the relative values. + uint32_t BestLoopSuccWeight = 0; + // FIXME: We also manually compute the probabilities to avoid quadratic + // behavior. + uint32_t WeightScale = 0; + uint32_t SumWeight = MBPI->getSumForBlock(*I, WeightScale); + for (MachineBasicBlock::succ_iterator SI = (*I)->succ_begin(), + SE = (*I)->succ_end(); + SI != SE; ++SI) { + if ((*SI)->isLandingPad()) + continue; + if (*SI == *I) + continue; + BlockChain &SuccChain = *BlockToChain[*SI]; + // Don't split chains, either this chain or the successor's chain. + if (&Chain == &SuccChain || *SI != *SuccChain.begin()) { + DEBUG(dbgs() << " " << (LoopBlockSet.count(*SI) ? "looping: " + : "exiting: ") + << getBlockName(*I) << " -> " + << getBlockName(*SI) << " (chain conflict)\n"); + continue; + } - // We only support rotating the loop chain as a unit, so look directly at the - // back of the chain and check that it has a backedge. - MachineBasicBlock *Latch = *llvm::prior(LoopChain.end()); - if (Latch == Header || - !Latch->isSuccessor(Header)) - return; + uint32_t SuccWeight = MBPI->getEdgeWeight(*I, *SI); + if (LoopBlockSet.count(*SI)) { + DEBUG(dbgs() << " looping: " << getBlockName(*I) << " -> " + << getBlockName(*SI) << " (" << SuccWeight << ")\n"); + if (BestLoopSucc && BestLoopSuccWeight >= SuccWeight) + continue; - // We need to analyze the branch and determine if rotating the loop will - // completely remove a branch. We bail if the analysis fails or we don't find - // an unconditional backedge. Note that this has to handle cases where the - // original order was rotated, and the chain has un-done it. As a result, - // there may not (yet) be the unconditional branch, but we can tell whether - // one will be added when updating the terminators. - SmallVector Cond; - MachineBasicBlock *TBB = 0, *FBB = 0; - if (TII->AnalyzeBranch(*Latch, TBB, FBB, Cond) || !Cond.empty()) - return; + BestLoopSucc = *SI; + BestLoopSuccWeight = SuccWeight; + continue; + } - // Next we need to find a split point. This rotate algorithm is *very* - // narrow, and it only tries to do the rotate when it can find a split point - // which is an analyzable branch that exits the loop. Splitting there allows - // us to form a fallthrough out of the loop and a conditional jump to the top - // of the loop after rotation. - MachineBasicBlock *NewBottom = 0, *NewTop = 0; - BlockChain::iterator SplitIt = LoopChain.end(); - for (BlockChain::reverse_iterator I = llvm::next(LoopChain.rbegin()), - E = LoopChain.rend(); - I != E; ++I) { - Cond.clear(); - TBB = FBB = 0; - // Ensure that this is a block with a conditional branch which we can - // analyze and re-form after rotating the loop. While it might be tempting - // to use the TBB or FBB output parameters from this, they will often be - // lies as they are only correct after the terminators have been updated, - // and we are mid-chain formation. - if (TII->AnalyzeBranch(**I, TBB, FBB, Cond) || Cond.empty()) - continue; - - // See if this block is an exiting block from the loop. LoopInfo provides - // a nice API for this, but it's actuall N*M runtime where N is the number - // of blocks in the loop and M is the number of successors. We can - // eliminate the N by doing this ourselves. - // FIXME: The LoopInfo datastructure should be improved for these types of - // queries. - MachineBasicBlock *ExitB = 0; - for (MachineBasicBlock::succ_iterator SI = (*I)->succ_begin(), SE = (*I)->succ_end(); - SI != SE; ++SI) { - if (!(*SI)->isLandingPad() && *SI != *I && !LoopBlockSet.count(*SI)) { - ExitB = *SI; - break; + BranchProbability SuccProb(SuccWeight / WeightScale, SumWeight); + BlockFrequency ExitEdgeFreq = MBFI->getBlockFreq(*I) * SuccProb; + DEBUG(dbgs() << " exiting: " << getBlockName(*I) << " -> " + << getBlockName(*SI) << " (" << ExitEdgeFreq << ")\n"); + // Note that we slightly bias this toward an existing layout successor to + // retain incoming order in the absence of better information. + // FIXME: Should we bias this more strongly? It's pretty weak. + if (!ExitingBB || ExitEdgeFreq > BestExitEdgeFreq || + ((*I)->isLayoutSuccessor(*SI) && + !(ExitEdgeFreq < BestExitEdgeFreq))) { + BestExitEdgeFreq = ExitEdgeFreq; + ExitingBB = *I; } } - if (!ExitB) + + // Restore the old exiting state, no viable looping successor was found. + if (!BestLoopSucc) { + ExitingBB = OldExitingBB; + BestExitEdgeFreq = OldBestExitEdgeFreq; continue; + } - NewBottom = *I; - NewTop = *llvm::prior(I); - SplitIt = I.base(); - break; - } - if (!NewBottom || !NewTop || - SplitIt == LoopChain.end() || SplitIt == LoopChain.begin()) - return; - assert(BlockToChain[NewBottom] == &LoopChain); - assert(BlockToChain[NewTop] == &LoopChain); - assert(*SplitIt == NewTop); - - // Rotate the chain and we're done. - DEBUG(dbgs() << "Rotating loop headed by: " << getBlockName(Header) << "\n" - << " new top: " << getBlockName(NewTop) << "\n" - << " new bottom: " << getBlockName(NewBottom) << "\n"); - std::rotate(LoopChain.begin(), SplitIt, LoopChain.end()); + // If this was best exiting block thus far, also record the looping block. + if (ExitingBB == *I) + LoopingBB = BestLoopSucc; + } + // Without a candidate exitting block or with only a single block in the + // loop, just use the loop header to layout the loop. + if (!ExitingBB || L.getNumBlocks() == 1) + return L.getHeader(); + + assert(LoopingBB && "All successors of a loop block are exit blocks!"); + DEBUG(dbgs() << " Best exiting block: " << getBlockName(ExitingBB) << "\n"); + DEBUG(dbgs() << " Best top block: " << getBlockName(LoopingBB) << "\n"); + return LoopingBB; } /// \brief Forms basic block chains from the natural loop structures. @@ -665,17 +680,21 @@ SmallVector BlockWorkList; BlockFilterSet LoopBlockSet(L.block_begin(), L.block_end()); - BlockChain &LoopChain = *BlockToChain[L.getHeader()]; + + MachineBasicBlock *LayoutTop = findBestLoopTop(F, L, LoopBlockSet); + BlockChain &LoopChain = *BlockToChain[LayoutTop]; // FIXME: This is a really lame way of walking the chains in the loop: we // walk the blocks, and use a set to prevent visiting a particular chain // twice. SmallPtrSet UpdatedPreds; + assert(BlockToChain[LayoutTop]->LoopPredecessors == 0); + UpdatedPreds.insert(BlockToChain[LayoutTop]); for (MachineLoop::block_iterator BI = L.block_begin(), BE = L.block_end(); BI != BE; ++BI) { BlockChain &Chain = *BlockToChain[*BI]; - if (!UpdatedPreds.insert(&Chain) || BI == L.block_begin()) + if (!UpdatedPreds.insert(&Chain)) continue; assert(Chain.LoopPredecessors == 0); @@ -695,8 +714,7 @@ BlockWorkList.push_back(*Chain.begin()); } - buildChain(*L.block_begin(), LoopChain, BlockWorkList, &LoopBlockSet); - rotateLoop(L, LoopChain, LoopBlockSet); + buildChain(LayoutTop, LoopChain, BlockWorkList, &LoopBlockSet); DEBUG({ // Crash at the end so we get all of the debugging output first. Modified: llvm/trunk/test/CodeGen/X86/block-placement.ll URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/block-placement.ll?rev=145183&r1=145182&r2=145183&view=diff ============================================================================== --- llvm/trunk/test/CodeGen/X86/block-placement.ll (original) +++ llvm/trunk/test/CodeGen/X86/block-placement.ll Sun Nov 27 07:34:33 2011 @@ -122,14 +122,14 @@ ; Check that we sink early exit blocks out of loop bodies. ; CHECK: test_loop_early_exits: ; CHECK: %entry -; CHECK: %body1 ; CHECK: %body2 ; CHECK: %body3 ; CHECK: %body4 -; CHECK: %exit +; CHECK: %body1 ; CHECK: %bail1 ; CHECK: %bail2 ; CHECK: %bail3 +; CHECK: %exit entry: br label %body1 @@ -346,9 +346,9 @@ ; single-source GCC. ; CHECK: unnatural_cfg2 ; CHECK: %entry -; CHECK: %loop.header ; CHECK: %loop.body1 ; CHECK: %loop.body2 +; CHECK: %loop.header ; CHECK: %loop.body3 ; CHECK: %loop.inner1.begin ; The end block is folded with %loop.body3... From baldrick at free.fr Sun Nov 27 12:07:43 2011 From: baldrick at free.fr (Duncan Sands) Date: Sun, 27 Nov 2011 19:07:43 +0100 Subject: [llvm-commits] [PATCHES] fix JIT optimization level bug In-Reply-To: References: Message-ID: <4ED27C6F.3020004@free.fr> Hi nobled, > The first two patches fix two different bugs introduced with r144788: > first, the CodeGenOpt enum was being cast into > addPassesToEmitMachineCode()'s optional 'bool DisableVerify' argument > after the old optimization argument was removed in the api change > (would a warning on implicitly casting enum to bool be a good idea?); > and second, the TargetMachine wasn't being created with the > optimization level requested. The rest are just code cleanups after > that. please don't send 8 patches attached to one email, please send 8 emails. Or, better, two emails each with one patch since logically speaking there are two different patches: fix up optlevel, move target triples about. In short, one logical change per email/patch please. > Okay to commit? They look OK, except why pass in the target triple as a string only to turn it into a triple object - why not pass in a triple object from the beginning? Ciao, Duncan. From baldrick at free.fr Sun Nov 27 12:11:49 2011 From: baldrick at free.fr (Duncan Sands) Date: Sun, 27 Nov 2011 19:11:49 +0100 Subject: [llvm-commits] [PATCHES] fix config.h include in public header In-Reply-To: References: Message-ID: <4ED27D65.4000308@free.fr> Hi nobled, > The first patch is just a cleanup while I was there; patches 2 and 3 > fix an issue where Valgrind.h includes config.h, causing macro > collisions with other projects like dragonegg (see r145131 / r145132). > > Okay to commit? what is cmakedefine01? I'm not competent to comment on the cmake stuff, but otherwise it looks good to me. Ciao, Duncan. From sabre at nondot.org Sun Nov 27 12:13:47 2011 From: sabre at nondot.org (Chris Lattner) Date: Sun, 27 Nov 2011 18:13:47 -0000 Subject: [llvm-commits] [llvm] r145188 - /llvm/trunk/test/Transforms/GlobalDCE/2009-09-03-MDNode.ll Message-ID: <20111127181347.EDF682A6C12D@llvm.org> Author: lattner Date: Sun Nov 27 12:13:47 2011 New Revision: 145188 URL: http://llvm.org/viewvc/llvm-project?rev=145188&view=rev Log: remove a test that is using old-style llvm.dbg intrinsics, apparently only fails on ppc and arm hosts. Removed: llvm/trunk/test/Transforms/GlobalDCE/2009-09-03-MDNode.ll Removed: llvm/trunk/test/Transforms/GlobalDCE/2009-09-03-MDNode.ll URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/GlobalDCE/2009-09-03-MDNode.ll?rev=145187&view=auto ============================================================================== --- llvm/trunk/test/Transforms/GlobalDCE/2009-09-03-MDNode.ll (original) +++ llvm/trunk/test/Transforms/GlobalDCE/2009-09-03-MDNode.ll (removed) @@ -1,264 +0,0 @@ -; RUN: opt < %s -globaldce | llc -O0 -o /dev/null - -%struct..0__pthread_mutex_s = type { i32, i32, i32, i32, i32, i32, %struct.__pthread_list_t } -%"struct.__gnu_cxx::_ConvertibleConcept" = type { i32 } -%struct.__pthread_list_t = type { %struct.__pthread_list_t*, %struct.__pthread_list_t* } -%struct.pthread_attr_t = type { i64, [48 x i8] } -%struct.pthread_mutex_t = type { %struct..0__pthread_mutex_s } - - at _ZL20__gthrw_pthread_oncePiPFvvE = alias weak i32 (i32*, void ()*)* @pthread_once ; [#uses=0] - at _ZL27__gthrw_pthread_getspecificj = alias weak i8* (i32)* @pthread_getspecific ; [#uses=0] - at _ZL27__gthrw_pthread_setspecificjPKv = alias weak i32 (i32, i8*)* @pthread_setspecific ; [#uses=0] - at _ZL22__gthrw_pthread_createPmPK14pthread_attr_tPFPvS3_ES3_ = alias weak i32 (i64*, %struct.pthread_attr_t*, i8* (i8*)*, i8*)* @pthread_create ; [#uses=0] - at _ZL22__gthrw_pthread_cancelm = alias weak i32 (i64)* @pthread_cancel ; [#uses=0] - at _ZL26__gthrw_pthread_mutex_lockP15pthread_mutex_t = alias weak i32 (%struct.pthread_mutex_t*)* @pthread_mutex_lock ; [#uses=0] - at _ZL29__gthrw_pthread_mutex_trylockP15pthread_mutex_t = alias weak i32 (%struct.pthread_mutex_t*)* @pthread_mutex_trylock ; [#uses=0] - at _ZL28__gthrw_pthread_mutex_unlockP15pthread_mutex_t = alias weak i32 (%struct.pthread_mutex_t*)* @pthread_mutex_unlock ; [#uses=0] - at _ZL26__gthrw_pthread_mutex_initP15pthread_mutex_tPK19pthread_mutexattr_t = alias weak i32 (%struct.pthread_mutex_t*, %"struct.__gnu_cxx::_ConvertibleConcept"*)* @pthread_mutex_init ; "*)*> [#uses=0] - at _ZL26__gthrw_pthread_key_createPjPFvPvE = alias weak i32 (i32*, void (i8*)*)* @pthread_key_create ; [#uses=0] - at _ZL26__gthrw_pthread_key_deletej = alias weak i32 (i32)* @pthread_key_delete ; [#uses=0] - at _ZL30__gthrw_pthread_mutexattr_initP19pthread_mutexattr_t = alias weak i32 (%"struct.__gnu_cxx::_ConvertibleConcept"*)* @pthread_mutexattr_init ; "*)*> [#uses=0] - at _ZL33__gthrw_pthread_mutexattr_settypeP19pthread_mutexattr_ti = alias weak i32 (%"struct.__gnu_cxx::_ConvertibleConcept"*, i32)* @pthread_mutexattr_settype ; "*, i32)*> [#uses=0] - at _ZL33__gthrw_pthread_mutexattr_destroyP19pthread_mutexattr_t = alias weak i32 (%"struct.__gnu_cxx::_ConvertibleConcept"*)* @pthread_mutexattr_destroy ; "*)*> [#uses=0] - -define weak void @_ZN9__gnu_cxx26__aux_require_boolean_exprIbEEvRKT_(i8* %__t) { -entry: - tail call void @llvm.dbg.func.start(metadata !0) - tail call void @llvm.dbg.stoppoint(i32 240, i32 0, metadata !2) - tail call void @llvm.dbg.region.end(metadata !0) - ret void -} - -define weak void @_ZN9__gnu_cxx19__function_requiresINS_19_ConvertibleConceptIjjEEEEvv() { -entry: - tail call void @llvm.dbg.func.start(metadata !8) - tail call void @llvm.dbg.stoppoint(i32 63, i32 0, metadata !2) - tail call void @llvm.dbg.region.end(metadata !8) - ret void -} - -define weak void @_ZN9__gnu_cxx19__function_requiresINS_21_InputIteratorConceptIPcEEEEvv() { -entry: - tail call void @llvm.dbg.func.start(metadata !11) - tail call void @llvm.dbg.stoppoint(i32 63, i32 0, metadata !2) - tail call void @llvm.dbg.region.end(metadata !11) - ret void -} - -define weak void @_ZN9__gnu_cxx19__function_requiresINS_21_InputIteratorConceptIPKcEEEEvv() { -entry: - tail call void @llvm.dbg.func.start(metadata !12) - tail call void @llvm.dbg.stoppoint(i32 63, i32 0, metadata !2) - tail call void @llvm.dbg.region.end(metadata !12) - ret void -} - -define weak void @_ZN9__gnu_cxx19__function_requiresINS_21_InputIteratorConceptIPwEEEEvv() { -entry: - tail call void @llvm.dbg.func.start(metadata !13) - tail call void @llvm.dbg.stoppoint(i32 63, i32 0, metadata !2) - tail call void @llvm.dbg.region.end(metadata !13) - ret void -} - -define weak void @_ZN9__gnu_cxx19__function_requiresINS_21_InputIteratorConceptIPKwEEEEvv() { -entry: - tail call void @llvm.dbg.func.start(metadata !14) - tail call void @llvm.dbg.stoppoint(i32 63, i32 0, metadata !2) - tail call void @llvm.dbg.region.end(metadata !14) - ret void -} - -define weak void @_ZN9__gnu_cxx19__function_requiresINS_26_LessThanComparableConceptIPwEEEEvv() { -entry: - tail call void @llvm.dbg.func.start(metadata !15) - tail call void @llvm.dbg.stoppoint(i32 63, i32 0, metadata !2) - tail call void @llvm.dbg.region.end(metadata !15) - ret void -} - -define weak void @_ZN9__gnu_cxx19__function_requiresINS_26_LessThanComparableConceptIPcEEEEvv() { -entry: - tail call void @llvm.dbg.func.start(metadata !16) - tail call void @llvm.dbg.stoppoint(i32 63, i32 0, metadata !2) - tail call void @llvm.dbg.region.end(metadata !16) - ret void -} - -define weak void @_ZN9__gnu_cxx19__function_requiresINS_26_LessThanComparableConceptIiEEEEvv() { -entry: - tail call void @llvm.dbg.func.start(metadata !17) - tail call void @llvm.dbg.stoppoint(i32 63, i32 0, metadata !2) - tail call void @llvm.dbg.region.end(metadata !17) - ret void -} - -define weak void @_ZN9__gnu_cxx19__function_requiresINS_26_LessThanComparableConceptIlEEEEvv() { -entry: - tail call void @llvm.dbg.func.start(metadata !18) - tail call void @llvm.dbg.stoppoint(i32 63, i32 0, metadata !2) - tail call void @llvm.dbg.region.end(metadata !18) - ret void -} - -define weak void @_ZN9__gnu_cxx19__function_requiresINS_26_LessThanComparableConceptIxEEEEvv() { -entry: - tail call void @llvm.dbg.func.start(metadata !19) - tail call void @llvm.dbg.stoppoint(i32 63, i32 0, metadata !2) - tail call void @llvm.dbg.region.end(metadata !19) - ret void -} - -define weak void @_ZN9__gnu_cxx19__function_requiresINS_26_LessThanComparableConceptIjEEEEvv() { -entry: - tail call void @llvm.dbg.func.start(metadata !20) - tail call void @llvm.dbg.stoppoint(i32 63, i32 0, metadata !2) - tail call void @llvm.dbg.region.end(metadata !20) - ret void -} - -define weak void @_ZN9__gnu_cxx19__function_requiresINS_22_OutputIteratorConceptISt19ostreambuf_iteratorIcSt11char_traitsIcEEcEEEEvv() { -entry: - tail call void @llvm.dbg.func.start(metadata !21) - tail call void @llvm.dbg.stoppoint(i32 63, i32 0, metadata !2) - tail call void @llvm.dbg.region.end(metadata !21) - ret void -} - -define weak void @_ZN9__gnu_cxx19__function_requiresINS_22_OutputIteratorConceptISt19ostreambuf_iteratorIwSt11char_traitsIwEEwEEEEvv() { -entry: - tail call void @llvm.dbg.func.start(metadata !22) - tail call void @llvm.dbg.stoppoint(i32 63, i32 0, metadata !2) - tail call void @llvm.dbg.region.end(metadata !22) - ret void -} - -define weak void @_ZN9__gnu_cxx19__function_requiresINS_28_RandomAccessIteratorConceptIPcEEEEvv() { -entry: - tail call void @llvm.dbg.func.start(metadata !23) - tail call void @llvm.dbg.stoppoint(i32 63, i32 0, metadata !2) - tail call void @llvm.dbg.region.end(metadata !23) - ret void -} - -define weak void @_ZN9__gnu_cxx19__function_requiresINS_28_RandomAccessIteratorConceptIPKcEEEEvv() { -entry: - tail call void @llvm.dbg.func.start(metadata !24) - tail call void @llvm.dbg.stoppoint(i32 63, i32 0, metadata !2) - tail call void @llvm.dbg.region.end(metadata !24) - ret void -} - -define weak void @_ZN9__gnu_cxx19__function_requiresINS_28_RandomAccessIteratorConceptINS_17__normal_iteratorIPKcSsEEEEEEvv() { -entry: - tail call void @llvm.dbg.func.start(metadata !25) - tail call void @llvm.dbg.stoppoint(i32 63, i32 0, metadata !2) - tail call void @llvm.dbg.region.end(metadata !25) - ret void -} - -define weak void @_ZN9__gnu_cxx19__function_requiresINS_28_RandomAccessIteratorConceptINS_17__normal_iteratorIPcSsEEEEEEvv() { -entry: - tail call void @llvm.dbg.func.start(metadata !26) - tail call void @llvm.dbg.stoppoint(i32 63, i32 0, metadata !2) - tail call void @llvm.dbg.region.end(metadata !26) - ret void -} - -define weak void @_ZN9__gnu_cxx19__function_requiresINS_28_RandomAccessIteratorConceptINS_17__normal_iteratorIPKwSbIwSt11char_traitsIwESaIwEEEEEEEEvv() { -entry: - tail call void @llvm.dbg.func.start(metadata !27) - tail call void @llvm.dbg.stoppoint(i32 63, i32 0, metadata !2) - tail call void @llvm.dbg.region.end(metadata !27) - ret void -} - -define weak void @_ZN9__gnu_cxx19__function_requiresINS_28_RandomAccessIteratorConceptINS_17__normal_iteratorIPwSbIwSt11char_traitsIwESaIwEEEEEEEEvv() { -entry: - tail call void @llvm.dbg.func.start(metadata !28) - tail call void @llvm.dbg.stoppoint(i32 63, i32 0, metadata !2) - tail call void @llvm.dbg.region.end(metadata !28) - ret void -} - -define weak void @_ZN9__gnu_cxx19__function_requiresINS_28_RandomAccessIteratorConceptIPwEEEEvv() { -entry: - tail call void @llvm.dbg.func.start(metadata !29) - tail call void @llvm.dbg.stoppoint(i32 63, i32 0, metadata !2) - tail call void @llvm.dbg.region.end(metadata !29) - ret void -} - -define weak void @_ZN9__gnu_cxx19__function_requiresINS_28_RandomAccessIteratorConceptIPKwEEEEvv() { -entry: - tail call void @llvm.dbg.func.start(metadata !30) - tail call void @llvm.dbg.stoppoint(i32 63, i32 0, metadata !2) - tail call void @llvm.dbg.region.end(metadata !30) - ret void -} - -declare void @llvm.dbg.func.start(metadata) nounwind readnone - -declare void @llvm.dbg.stoppoint(i32, i32, metadata) nounwind readnone - -declare void @llvm.dbg.region.end(metadata) nounwind readnone - -declare extern_weak i32 @pthread_once(i32*, void ()*) - -declare extern_weak i8* @pthread_getspecific(i32) - -declare extern_weak i32 @pthread_setspecific(i32, i8*) - -declare extern_weak i32 @pthread_create(i64*, %struct.pthread_attr_t*, i8* (i8*)*, i8*) - -declare extern_weak i32 @pthread_cancel(i64) - -declare extern_weak i32 @pthread_mutex_lock(%struct.pthread_mutex_t*) - -declare extern_weak i32 @pthread_mutex_trylock(%struct.pthread_mutex_t*) - -declare extern_weak i32 @pthread_mutex_unlock(%struct.pthread_mutex_t*) - -declare extern_weak i32 @pthread_mutex_init(%struct.pthread_mutex_t*, %"struct.__gnu_cxx::_ConvertibleConcept"*) - -declare extern_weak i32 @pthread_key_create(i32*, void (i8*)*) - -declare extern_weak i32 @pthread_key_delete(i32) - -declare extern_weak i32 @pthread_mutexattr_init(%"struct.__gnu_cxx::_ConvertibleConcept"*) - -declare extern_weak i32 @pthread_mutexattr_settype(%"struct.__gnu_cxx::_ConvertibleConcept"*, i32) - -declare extern_weak i32 @pthread_mutexattr_destroy(%"struct.__gnu_cxx::_ConvertibleConcept"*) - -!0 = metadata !{i32 458798, i32 0, metadata !1, metadata !"__aux_require_boolean_expr", metadata !"__aux_require_boolean_expr", metadata !"_ZN9__gnu_cxx26__aux_require_boolean_exprIbEEvRKT_", metadata !2, i32 239, metadata !3, i1 false, i1 true} -!1 = metadata !{i32 458769, i32 0, i32 4, metadata !"concept-inst.cc", metadata !"/home/buildbot/buildslave/llvm-x86_64-linux-selfhost/llvm-gcc.obj/x86_64-unknown-linux-gnu/libstdc++-v3/src/../../../../llvm-gcc.src/libstdc++-v3/src", metadata !"4.2.1 (Based on Apple Inc. build 5649) (LLVM build)", i1 true, i1 true, metadata !"", i32 0} -!2 = metadata !{i32 458769, i32 0, i32 4, metadata !"boost_concept_check.h", metadata !"/home/buildbot/buildslave/llvm-x86_64-linux-selfhost/llvm-gcc.obj/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits", metadata !"4.2.1 (Based on Apple Inc. build 5649) (LLVM build)", i1 false, i1 true, metadata !"", i32 0} -!3 = metadata !{i32 458773, metadata !1, metadata !"", metadata !1, i32 0, i64 0, i64 0, i64 0, i32 0, null, metadata !4, i32 0} -!4 = metadata !{null, metadata !5} -!5 = metadata !{i32 458768, metadata !1, metadata !"", metadata !1, i32 0, i64 64, i64 64, i64 0, i32 0, metadata !6} -!6 = metadata !{i32 458790, metadata !1, metadata !"", metadata !1, i32 0, i64 8, i64 8, i64 0, i32 0, metadata !7} -!7 = metadata !{i32 458788, metadata !1, metadata !"bool", metadata !1, i32 0, i64 8, i64 8, i64 0, i32 0, i32 2} -!8 = metadata !{i32 458798, i32 0, metadata !1, metadata !"__function_requires<__gnu_cxx::_ConvertibleConcept >", metadata !"__function_requires<__gnu_cxx::_ConvertibleConcept >", metadata !"_ZN9__gnu_cxx19__function_requiresINS_19_ConvertibleConceptIjjEEEEvv", metadata !2, i32 61, metadata !9, i1 false, i1 true} -!9 = metadata !{i32 458773, metadata !1, metadata !"", metadata !1, i32 0, i64 0, i64 0, i64 0, i32 0, null, metadata !10, i32 0} -!10 = metadata !{null} -!11 = metadata !{i32 458798, i32 0, metadata !1, metadata !"__function_requires<__gnu_cxx::_InputIteratorConcept >", metadata !"__function_requires<__gnu_cxx::_InputIteratorConcept >", metadata !"_ZN9__gnu_cxx19__function_requiresINS_21_InputIteratorConceptIPcEEEEvv", metadata !2, i32 61, metadata !9, i1 false, i1 true} -!12 = metadata !{i32 458798, i32 0, metadata !1, metadata !"__function_requires<__gnu_cxx::_InputIteratorConcept >", metadata !"__function_requires<__gnu_cxx::_InputIteratorConcept >", metadata !"_ZN9__gnu_cxx19__function_requiresINS_21_InputIteratorConceptIPKcEEEEvv", metadata !2, i32 61, metadata !9, i1 false, i1 true} -!13 = metadata !{i32 458798, i32 0, metadata !1, metadata !"__function_requires<__gnu_cxx::_InputIteratorConcept >", metadata !"__function_requires<__gnu_cxx::_InputIteratorConcept >", metadata !"_ZN9__gnu_cxx19__function_requiresINS_21_InputIteratorConceptIPwEEEEvv", metadata !2, i32 61, metadata !9, i1 false, i1 true} -!14 = metadata !{i32 458798, i32 0, metadata !1, metadata !"__function_requires<__gnu_cxx::_InputIteratorConcept >", metadata !"__function_requires<__gnu_cxx::_InputIteratorConcept >", metadata !"_ZN9__gnu_cxx19__function_requiresINS_21_InputIteratorConceptIPKwEEEEvv", metadata !2, i32 61, metadata !9, i1 false, i1 true} -!15 = metadata !{i32 458798, i32 0, metadata !1, metadata !"__function_requires<__gnu_cxx::_LessThanComparableConcept >", metadata !"__function_requires<__gnu_cxx::_LessThanComparableConcept >", metadata !"_ZN9__gnu_cxx19__function_requiresINS_26_LessThanComparableConceptIPwEEEEvv", metadata !2, i32 61, metadata !9, i1 false, i1 true} -!16 = metadata !{i32 458798, i32 0, metadata !1, metadata !"__function_requires<__gnu_cxx::_LessThanComparableConcept >", metadata !"__function_requires<__gnu_cxx::_LessThanComparableConcept >", metadata !"_ZN9__gnu_cxx19__function_requiresINS_26_LessThanComparableConceptIPcEEEEvv", metadata !2, i32 61, metadata !9, i1 false, i1 true} -!17 = metadata !{i32 458798, i32 0, metadata !1, metadata !"__function_requires<__gnu_cxx::_LessThanComparableConcept >", metadata !"__function_requires<__gnu_cxx::_LessThanComparableConcept >", metadata !"_ZN9__gnu_cxx19__function_requiresINS_26_LessThanComparableConceptIiEEEEvv", metadata !2, i32 61, metadata !9, i1 false, i1 true} -!18 = metadata !{i32 458798, i32 0, metadata !1, metadata !"__function_requires<__gnu_cxx::_LessThanComparableConcept >", metadata !"__function_requires<__gnu_cxx::_LessThanComparableConcept >", metadata !"_ZN9__gnu_cxx19__function_requiresINS_26_LessThanComparableConceptIlEEEEvv", metadata !2, i32 61, metadata !9, i1 false, i1 true} -!19 = metadata !{i32 458798, i32 0, metadata !1, metadata !"__function_requires<__gnu_cxx::_LessThanComparableConcept >", metadata !"__function_requires<__gnu_cxx::_LessThanComparableConcept >", metadata !"_ZN9__gnu_cxx19__function_requiresINS_26_LessThanComparableConceptIxEEEEvv", metadata !2, i32 61, metadata !9, i1 false, i1 true} -!20 = metadata !{i32 458798, i32 0, metadata !1, metadata !"__function_requires<__gnu_cxx::_LessThanComparableConcept >", metadata !"__function_requires<__gnu_cxx::_LessThanComparableConcept >", metadata !"_ZN9__gnu_cxx19__function_requiresINS_26_LessThanComparableConceptIjEEEEvv", metadata !2, i32 61, metadata !9, i1 false, i1 true} -!21 = metadata !{i32 458798, i32 0, metadata !1, metadata !"__function_requires<__gnu_cxx::_OutputIteratorConcept >, char> >", metadata !"__function_requires<__gnu_cxx::_OutputIteratorConcept >, char> >", metadata !"_ZN9__gnu_cxx19__function_requiresINS_22_OutputIteratorConceptISt19ostreambuf_iteratorIcSt11char_traitsIcEEcEEEEvv", metadata !2, i32 61, metadata !9, i1 false, i1 true} -!22 = metadata !{i32 458798, i32 0, metadata !1, metadata !"__function_requires<__gnu_cxx::_OutputIteratorConcept >, wchar_t> >", metadata !"__function_requires<__gnu_cxx::_OutputIteratorConcept >, wchar_t> >", metadata !"_ZN9__gnu_cxx19__function_requiresINS_22_OutputIteratorConceptISt19ostreambuf_iteratorIwSt11char_traitsIwEEwEEEEvv", metadata !2, i32 61, metadata !9, i1 false, i1 true} -!23 = metadata !{i32 458798, i32 0, metadata !1, metadata !"__function_requires<__gnu_cxx::_RandomAccessIteratorConcept >", metadata !"__function_requires<__gnu_cxx::_RandomAccessIteratorConcept >", metadata !"_ZN9__gnu_cxx19__function_requiresINS_28_RandomAccessIteratorConceptIPcEEEEvv", metadata !2, i32 61, metadata !9, i1 false, i1 true} -!24 = metadata !{i32 458798, i32 0, metadata !1, metadata !"__function_requires<__gnu_cxx::_RandomAccessIteratorConcept >", metadata !"__function_requires<__gnu_cxx::_RandomAccessIteratorConcept >", metadata !"_ZN9__gnu_cxx19__function_requiresINS_28_RandomAccessIteratorConceptIPKcEEEEvv", metadata !2, i32 61, metadata !9, i1 false, i1 true} -!25 = metadata !{i32 458798, i32 0, metadata !1, metadata !"__function_requires<__gnu_cxx::_RandomAccessIteratorConcept<__gnu_cxx::__normal_iterator, std::allocator > > > >", metadata !"__function_requires<__gnu_cxx::_RandomAccessIteratorConcept<__gnu_cxx::__normal_iterator, std::allocator > > > >", metadata !"_ZN9__gnu_cxx19__function_requiresINS_28_RandomAccessIteratorConceptINS_17__normal_iteratorIPKcSsEEEEEEvv", metadata !2, i32 61, metadata !9, i1 false, i1 true} -!26 = metadata !{i32 458798, i32 0, metadata !1, metadata !"__function_requires<__gnu_cxx::_RandomAccessIteratorConcept<__gnu_cxx::__normal_iterator, std::allocator > > > >", metadata !"__function_requires<__gnu_cxx::_RandomAccessIteratorConcept<__gnu_cxx::__normal_iterator, std::allocator > > > >", metadata !"_ZN9__gnu_cxx19__function_requiresINS_28_RandomAccessIteratorConceptINS_17__normal_iteratorIPcSsEEEEEEvv", metadata !2, i32 61, metadata !9, i1 false, i1 true} -!27 = metadata !{i32 458798, i32 0, metadata !1, metadata !"__function_requires<__gnu_cxx::_RandomAccessIteratorConcept<__gnu_cxx::__normal_iterator, std::allocator > > > >", metadata !"__function_requires<__gnu_cxx::_RandomAccessIteratorConcept<__gnu_cxx::__normal_iterator, std::allocator > > > >", metadata !"_ZN9__gnu_cxx19__function_requiresINS_28_RandomAccessIteratorConceptINS_17__normal_iteratorIPKwSbIwSt11char_traitsIwESaIwEEEEEEEEvv", metadata !2, i32 61, metadata !9, i1 false, i1 true} -!28 = metadata !{i32 458798, i32 0, metadata !1, metadata !"__function_requires<__gnu_cxx::_RandomAccessIteratorConcept<__gnu_cxx::__normal_iterator, std::allocator > > > >", metadata !"__function_requires<__gnu_cxx::_RandomAccessIteratorConcept<__gnu_cxx::__normal_iterator, std::allocator > > > >", metadata !"_ZN9__gnu_cxx19__function_requiresINS_28_RandomAccessIteratorConceptINS_17__normal_iteratorIPwSbIwSt11char_traitsIwESaIwEEEEEEEEvv", metadata !2, i32 61, metadata !9, i1 false, i1 true} -!29 = metadata !{i32 458798, i32 0, metadata !1, metadata !"__function_requires<__gnu_cxx::_RandomAccessIteratorConcept >", metadata !"__function_requires<__gnu_cxx::_RandomAccessIteratorConcept >", metadata !"_ZN9__gnu_cxx19__function_requiresINS_28_RandomAccessIteratorConceptIPwEEEEvv", metadata !2, i32 61, metadata !9, i1 false, i1 true} -!30 = metadata !{i32 458798, i32 0, metadata !1, metadata !"__function_requires<__gnu_cxx::_RandomAccessIteratorConcept >", metadata !"__function_requires<__gnu_cxx::_RandomAccessIteratorConcept >", metadata !"_ZN9__gnu_cxx19__function_requiresINS_28_RandomAccessIteratorConceptIPKwEEEEvv", metadata !2, i32 61, metadata !9, i1 false, i1 true} From chandlerc at google.com Sun Nov 27 12:22:26 2011 From: chandlerc at google.com (Chandler Carruth) Date: Sun, 27 Nov 2011 10:22:26 -0800 Subject: [llvm-commits] [PATCHES] fix config.h include in public header In-Reply-To: <4ED27D65.4000308@free.fr> References: <4ED27D65.4000308@free.fr> Message-ID: On Sun, Nov 27, 2011 at 10:11 AM, Duncan Sands wrote: > what is cmakedefine01? Looks like a typo. Once this is fixed, I'm happy w/ the CMake aspects of this patch. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20111127/cc1f67d0/attachment.html From sabre at nondot.org Sun Nov 27 12:47:38 2011 From: sabre at nondot.org (Chris Lattner) Date: Sun, 27 Nov 2011 18:47:38 -0000 Subject: [llvm-commits] [llvm] r145190 - /llvm/trunk/docs/ReleaseNotes.html Message-ID: <20111127184738.2E9B32A6C12D@llvm.org> Author: lattner Date: Sun Nov 27 12:47:37 2011 New Revision: 145190 URL: http://llvm.org/viewvc/llvm-project?rev=145190&view=rev Log: some random notes. Modified: llvm/trunk/docs/ReleaseNotes.html Modified: llvm/trunk/docs/ReleaseNotes.html URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes.html?rev=145190&r1=145189&r2=145190&view=diff ============================================================================== --- llvm/trunk/docs/ReleaseNotes.html (original) +++ llvm/trunk/docs/ReleaseNotes.html Sun Nov 27 12:47:37 2011 @@ -45,7 +45,8 @@
This document contains the release notes for the LLVM Compiler Infrastructure, release 3.0. Here we describe the status of LLVM, including - major improvements from the previous release and significant known problems. + major improvements from the previous release, improvements in various + subprojects of LLVM, and some of the current users of the code. All LLVM releases may be downloaded from the LLVM releases web site.
@@ -62,14 +63,6 @@
-
@@ -99,7 +92,7 @@ provides a modular, library-based architecture that makes it suitable for creating or integrating with other development tools. Clang is considered a production-quality compiler for C, Objective-C, C++ and Objective-C++ on x86 - (32- and 64-bit), and for darwin/arm targets.
+ (32- and 64-bit), and for Darwin/ARM targets.

In the LLVM 3.0 time-frame, the Clang team has made many improvements:
@@ -109,9 +102,9 @@
Improved support for the C++ - 2011 standard, including implementations of non-static data member - initializers, alias templates, delegating constructors, the range-based - for loop, and implicitly-generated move constructors and move assignment + 2011 standard (aka "C++'0x"), including implementations of non-static data member + initializers, alias templates, delegating constructors, range-based + for loops, and implicitly-generated move constructors and move assignment operators, among others.

Implemented support for some features of the upcoming C1x standard, @@ -127,18 +120,18 @@ Automatic Reference Counting (ARC) and an improved memory model cleanly separating object and C memory.
-
A migration tool for moving legacy code to ARC
+
A migration tool for moving manual retain/release code to ARC

Better support for data hiding, allowing instance variables to be declared in implementation contexts or class extensions
-
Weak linking for classes
+
Weak linking support for Objective-C classes

Improved static type checking by inferring the return type of methods such as +alloc and -init.

-Function *ExcIntr = Intrinsic::getDeclaration(TheModule, - Intrinsic::eh_exception); -Function *SlctrIntr = Intrinsic::getDeclaration(TheModule, - Intrinsic::eh_selector); - -// The exception pointer. -Value *ExnPtr = Builder.CreateCall(ExcIntr, "exc_ptr"); - -std::vector<Value*> Args; -Args.push_back(ExnPtr); -Args.push_back(Builder.CreateBitCast(Personality, - Type::getInt8PtrTy(Context))); - -// Add selector clauses to Args. - -// The selector call. -Builder.CreateCall(SlctrIntr, Args, "exc_sel"); -

-LandingPadInst *LPadInst = - Builder.CreateLandingPad(StructType::get(Int8PtrTy, Int32Ty, NULL), - Personality, 0); - -Value *LPadExn = Builder.CreateExtractValue(LPadInst, 0); -Builder.CreateStore(LPadExn, getExceptionSlot()); - -Value *LPadSel = Builder.CreateExtractValue(LPadInst, 1); -Builder.CreateStore(LPadSel, getEHSelectorSlot()); -

-// Adding a catch clause -Constant *TypeInfo = getTypeInfo(); -LPadInst->addClause(TypeInfo); - -// Adding a C++ catch-all -LPadInst->addClause(Constant::getNullValue(Builder.getInt8PtrTy())); - -// Adding a cleanup -LPadInst->setCleanup(true); - -// Adding a filter clause -std::vector<Constant*> TypeInfos; -Constant *TypeInfo = getFilterTypeInfo(); -TypeInfos.push_back(Builder.CreateBitCast(TypeInfo, Builder.getInt8PtrTy())); - -ArrayType *FilterTy = ArrayType::get(Int8PtrTy, TypeInfos.size()); -LPadInst->addClause(ConstantArray::get(FilterTy, TypeInfos)); -

-Type *UnwindDataTy = StructType::get(Builder.getInt8PtrTy(), - Builder.getInt32Ty(), NULL); -Value *UnwindData = UndefValue::get(UnwindDataTy); -Value *ExcPtr = Builder.CreateLoad(getExceptionObjSlot()); -Value *ExcSel = Builder.CreateLoad(getExceptionSelSlot()); -UnwindData = Builder.CreateInsertValue(UnwindData, ExcPtr, 0, "exc_ptr"); -UnwindData = Builder.CreateInsertValue(UnwindData, ExcSel, 1, "exc_sel"); -Builder.CreateResume(UnwindData); -

Middle End

Test Polly

FAUST Real-Time Audio Signal Processing Language

Glasgow Haskell Compiler (GHC)

The Julia Programming Language

LanguageKit and Pragmatic Smalltalk

The ZooLib C++ Cross-Platform Application Framework

-LLBrowse: IR Browser -

VMKit @@ -286,7 +274,24 @@

+LLBrowse: IR Browser +

-LLVM IR and Core Improvements -

+LLVM IR and Core Improvements +

- Experimental features included with this release -

- Known problems with the X86 back-end -

- Known problems with the PowerPC back-end -

- Known problems with the ARM back-end -

- Known problems with the SPARC back-end -

- Known problems with the MIPS back-end -

- Known problems with the Alpha back-end -

- Known problems with the C back-end -

-Loop Optimization Improvements -

Segmented Stacks

Windows (32-bit)