similar to: [LLVMdev] LLVM and loop optimizations

I'm probably missing something simple here but in: CGDebugInfo.h: std::vector<std::pair<void *, llvm::WeakVH> >ReplaceMap; but then in CGDebugInfo.cpp: llvm::DIType TC = getTypeOrNull(Ty); void * v = Ty.getAsOpaquePtr(); std::pair<void *, llvm::WeakVH> tmp = std::make_pair(v, TC); if (TC.Verify() && TC.isForwardDecl())

Hi Ben, Thanks that helped a lot. The problem seems to be that with the move to C++11 we now have: void std::vector<_Ty>::push_back(std::pair<_Ty1,_Ty2> &&)' and there no conversion operator that can be applied to convert: 'std::pair<_Ty1,_Ty2>' to 'std::pair<_Ty3,_Ty4> && Where: [ _Ty1=void *,

On 09.08.2012, at 19:43, "Gaster, Benedict" <Benedict.Gaster at amd.com> wrote: > I’m probably missing something simple here but in: > > CGDebugInfo.h: > > std::vector<std::pair<void *, llvm::WeakVH> >ReplaceMap; > > but then in > > CGDebugInfo.cpp: > > llvm::DIType TC = getTypeOrNull(Ty); > > void * v =

Awesome, thanks! Now I have another question. I have a matrix multiplication code. This is my code: #include <stdio.h> #include <stdlib.h> #define n 4 int main(int argc, char *argv[]) { int i, j, k; int A[n][n], B[n][n], C[n][n]; for(i=0;i<n;i++){ for(j=0;j<n;j++){ A[i][j] = 1; B[i][j] = 2; C[i][j] = 0; } }

Dear LLVM developers, Recently I want to try the pass '-loop-unroll-and-jam' to observe how the IR is transformed, but I don't see the IR changed after doing the following steps. Here are the details for preparing my experiment and I have tried the LLVM 6, 7 and 8: 1) Simple 2D array source code (loop.c) is given ``` #define M 32768 #define N 32768 double a[M][N], b[M][N],

The following code causes opt to not terminate! With TOT this morning, and of a week ago: clang foo.c and clang -O1 foo.c work fine. clang -O2 foo.c and clang -O3 foo.c do not terminate. (At least after 10 minutes) If I generate the bit code (clang-cc -emit-llvmbc) and then run: opt -O3 foo.bc it does not terminate. //foo.c int get_id(int); typedef short

Hi, Ivan: Sorry for deviating the topic a bit. As I told you before I'm a LLVM newbie, I cannot give you conclusive answer if the proposed interface is ok or not. My personal opinion on these two interface is summarized bellow: - hasZeroCostLoop() pro: it is clearly state the HW support. con: Having zero cost loop doesn't imply the benefit HW loop could achieve.

Hi Eli, Yep I was being stupid. Please find attached a patch for initial changes to get MASM working. There is still one problem that I am looking into around changing alignments within SEGMENTS. The problem is that MASM allows 2,4,16,256 alignments, default being 16, but LLVM is sometimes generating 32 alignment, for example, consider the following code: float bar(float fy, float fx) {

Hi, If we add multiple loop passes to the pass manager in PassManagerBuilder.cpp consecutively without any func/module pass in between, I used to think they would belong to the same loop pass manager. But it does not seem to be the case. For example for this code snippet PM.add(createIndVarSimplifyPass()); // Canonicalize indvars MPM.add(createLoopIdiomPass()); //

Hi Mon Ping, Discussing this with others in AMD it came up if it is possible for LLVM to take a program that has a reducible graph (any C code without goto/setjmp) and generate one that is irreducible? If it is the case that the code is actually structured coming in, a simple pattern matcher could turn everything into if/endif and so on. Ben On 14/08/2008 18:39, "Mon P Wang"

Hi Eli, Thanks for the response I have one question inline. Regards, Ben [...] > The main problem that I have hit is regarding the use of CL register in the > shift instructions. The problem is that ATT syntax states that it should be > referenced as "%cl" while Intel says just "cl" but these references occur in > X86InstInfo.td and this means that it is shared

<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10pt" ><div dir="ltr" ><font face="AppleSystemUIFont" size="3" >LoopUnrollAndJamPass is currently a loop pass. It is added in a LPM with only itself.</font><br><font face="AppleSystemUIFont"

On 2008-07-07, at 05:40, Benedict Gaster wrote: > %r1 = call i32 @llvm.atomic.load.add.p0i32( i32 addrspace(0)* > %ptr0, i32 4) > %r2 = call i32 @llvm.atomic.load.add.p11i32( i32 addrspace(11)* > %ptr11, i32 4) > call void @llvm.memory.barrier(i1 true, i1 true, i1 false, i1 false, > i32 11, i1 false) ; force read-modify-write %ptr11 to complete > > A problem with

Hi Eli, Sorry about that Visual Studio seems to have inserted tabs and I used an internal diff tool. Anyway, I synced TOT LLVM and made the changes with Emacs and the svn diff is attached. Regards, Ben -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Eli Friedman Sent: Tuesday, June 16, 2009 11:19 AM To: LLVM Developers

On Fri, Sep 4, 2009 at 9:37 AM, Gaster, Benedict<Benedict.Gaster at amd.com> wrote: > The following code causes opt to not terminate! Please flle in bugzilla with a bitcode testcase; it would help to reduce the testcase using bugpoint. -Eli

On Mon, Jun 15, 2009 at 11:21 PM, Gaster, Benedict<Benedict.Gaster at amd.com> wrote: > I can get this two work with additional changes to X86InstrInfocpp but > the problem I have with this approach is that it introduces a lot of > duplication, when all I really want to do is parameterize the final > field in the string "shl{b}\t{%cl, $dst|$dst, %CL}". I was wondering

On Tue, Jun 16, 2009 at 9:39 AM, Gaster, Benedict<Benedict.Gaster at amd.com> wrote: > Hi Eli, > > Yep I was being stupid. > > Please find attached a patch for initial changes to get MASM working. Patch looks fine except that it has tabs (LLVM uses only spaces for indentation). Also, can you generate the patch using "svn diff"? It's currently in some unusual

I would like to use the LLVM x86 code generator to emit Intel syntax that is compatible with Microsoft's MASM 9.x. Taking the TOT LLVM, from last week, I have found a number of changes that are required to make this work, most of which are straight forward but a couple I wanted to check with the group to see what people thought was the best thing to do. In particular, I have made all necessary

Hello Yes, I agree that the SCEV cannot be simplified. Is my understanding correct that it is passed to a function like "isKnownNegative"? Which could still be able to prove is always true. The delinearisation may be valid, depending on exactly how you define delinearisation (under what conditions it should be giving results). It would be invalid for DA to return a dependency of [0

Consider the following C code: typedef __attribute__(( ext_vector_type(2) )) float float2; typedef __attribute__(( ext_vector_type(2) )) __attribute__(( aligned(4) )) float float2_align2; void foo(void) { const float * p; size_t offset; float2 tmp = *((float2_align2 *)(p+offset)); } When compiled with clang ‹emit-llvm I get: define void @foo() { entry: %p = alloca float*, align 4