similar to: [LLVMdev] debug metadata incomplete for array arguments to functions?

On Jul 13, 2011, at 9:56 PM, Eli Bendersky wrote: > Hello, > > Consider the following two functions: > > void foo(int* arg_ptr) { > ... > } > > void bar(int arg_arr[42]) { > ... > } > > ------ > > According to the C standard, both arguments will be passed to the function as pointers. However, in the debug information metadata generated in LLVM, it

> > This reflects the compiler's view of things correctly, but is problematic > for a debugger. The debugger should know that arg_arr refers to a 42-element > array and isn't just a pointer into a buffer of unspecified length. This is > something the user would expect. > > On the other hand, the debugger should also get the information that > arg_arr is actually a

On 15 July 2011 06:35, Eli Bendersky <eliben at gmail.com> wrote: > >> > This reflects the compiler's view of things correctly, but is >> > problematic for a debugger. The debugger should know that arg_arr refers to >> > a 42-element array and isn't just a pointer into a buffer of unspecified >> > length. This is something the user would expect.

On 15 July 2011 05:35, Eli Bendersky <eliben at gmail.com> wrote: > Suppose one would start writing a patch to Clang to rectify this, how would > this information be encoded in the debug metadata, given the dual nature of > the arg_arr argument? Is there a mechanism to support it, or is an extension > required? Hi Eli, The first thing is to make sure it actually makes any

On Jul 14, 2011, at 9:35 PM, Eli Bendersky <eliben at gmail.com> wrote: > > > This reflects the compiler's view of things correctly, but is problematic for a debugger. The debugger should know that arg_arr refers to a 42-element array and isn't just a pointer into a buffer of unspecified length. This is something the user would expect. > > On the other hand, the

On Fri, Jul 15, 2011 at 11:27, Renato Golin <renato.golin at arm.com> wrote: > On 15 July 2011 05:35, Eli Bendersky <eliben at gmail.com> wrote: > > Suppose one would start writing a patch to Clang to rectify this, how > would > > this information be encoded in the debug metadata, given the dual nature > of > > the arg_arr argument? Is there a mechanism to

Thanks for the alternatives! I am trying the 'extracting sub-function' approach. However, it seems I can't get the 'subfunction' to pass the verifier. This is my subfunction: define void @main_extern([8 x i8]* %arg_ptr) { entrypoint: %0 = getelementptr [8 x i8]* %arg_ptr, i32 0 %1 = bitcast [8 x i8]* %0 to i64* %2 = load i64* %1 %3 = getelementptr [8 x i8]*

----- Original Message ----- > Thanks for the alternatives! > > I am trying the 'extracting sub-function' approach. However, it seems > I > can't get the 'subfunction' to pass the verifier. This is my > subfunction: > > define void @main_extern([8 x i8]* %arg_ptr) { > entrypoint: > %0 = getelementptr [8 x i8]* %arg_ptr, i32 0 > %1 =

----- Original Message ----- > Bingo! That works (when coming from C source) > > Now, I have a serious problem. I am not coming from C but I build the > function with the builder. I am also forced to change the signature > and > load the pointers a,b,c afterwards: > > define void @bar([8 x i8]* nocapture readonly %arg_ptr) #0 { > entrypoint: > %0 = bitcast [8 x

Bingo! That works (when coming from C source) Now, I have a serious problem. I am not coming from C but I build the function with the builder. I am also forced to change the signature and load the pointers a,b,c afterwards: define void @bar([8 x i8]* nocapture readonly %arg_ptr) #0 { entrypoint: %0 = bitcast [8 x i8]* %arg_ptr to i32* %1 = load i32* %0, align 4 %2 = getelementptr [8 x

Hi Hal! I am using the 'x86_64' target. Below the complete module dump and here the command line: opt -march=x64-64 -loop-vectorize -debug-only=loop-vectorize -S test.ll Frank ; ModuleID = 'test.ll' target datalayout = "e-p:64:64:64-S128-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f16:16:16-f32:32:32-f64:64:64-f128:128:128-v64:64:64-v128:12

>>> LV: The Widest type: 32 bits. >>> LV: The Widest register is: 32 bits. Yep, we don’t pick up the right TTI. Try -march=x86-64 (or leave it out) you already have this info in the triple. Then it should work (does for me with your example below). On Oct 26, 2013, at 2:16 PM, Frank Winter <fwinter at jlab.org> wrote: > Hi Hal! > > I am using the

My function implements a simple loop: void bar( int start, int end, float* A, float* B, float* C) { for (int i=start; i<end;++i) A[i] = B[i] * C[i]; } This looks pretty much like the standard example. However, I built the function with the IRBuilder, thus not coming from C and clang. Also I changed slightly the function's signature: define void @bar([8 x i8]* %arg_ptr) {

I would need this to work when calling the vectorizer through the function pass manager. Unfortunately I am having the same problem there: LV: The Widest type: 32 bits. LV: The Widest register is: 32 bits. It's not picking the target information, although I tried with and without the target triple in the module. Any idea what could be wrong? Frank On 26/10/13 15:54, Hal Finkel wrote:

----- Original Message ----- > >>> LV: The Widest type: 32 bits. > >>> LV: The Widest register is: 32 bits. > > Yep, we don’t pick up the right TTI. > > Try -march=x86-64 (or leave it out) you already have this info in the > triple. > > Then it should work (does for me with your example below). That may depend on what CPU is picks by default; Frank,

Hi Frank, Sent from my iPhone > On Oct 26, 2013, at 10:03 AM, Frank Winter <fwinter at jlab.org> wrote: > > My function implements a simple loop: > > void bar( int start, int end, float* A, float* B, float* C) > { > for (int i=start; i<end;++i) > A[i] = B[i] * C[i]; > } > > This looks pretty much like the standard example. However, I built

----- Original Message ----- > Hi Arnold, > > adding '-debug-only=loop-vectorize' to the command gives: > > LV: Checking a loop in "bar" > LV: Found a loop: L0 > LV: Found an induction variable. > LV: Found an unidentified write ptr: %7 = load float** %6 > LV: Found an unidentified read ptr: %10 = load float** %9 > LV: Found an unidentified

Hi Frank, On Oct 26, 2013, at 6:29 PM, Frank Winter <fwinter at jlab.org> wrote: > I would need this to work when calling the vectorizer through > the function pass manager. Unfortunately I am having the same > problem there: I am not sure which function pass manager you are referring here. I assume you create your own (you are not using opt but configure your own pass

Hi Arnold, thanks for the detailed setup. Still, I haven't figured out the right thing to do. I would need only the native target since all generated code will execute on the JIT execution machine (right now, the old JIT interface). There is no need for other targets. Maybe it would be good to ask specific questions: How do I get the triple for the native target? How do I setup the

Hi Arnold, adding '-debug-only=loop-vectorize' to the command gives: LV: Checking a loop in "bar" LV: Found a loop: L0 LV: Found an induction variable. LV: Found an unidentified write ptr: %7 = load float** %6 LV: Found an unidentified read ptr: %10 = load float** %9 LV: Found an unidentified read ptr: %13 = load float** %12 LV: We need to do 2 pointer comparisons. LV: We