search for: trace_integ

...e, or unneeded loads? In my generator I end up having a lot of the same load. For example here I keep loading "@pt" which will always be the same value. %16 = load %1** @pt, align 8 %17 = getelementptr inbounds %1* %16, i64 0, i32 2, i32 0 %18 = load i32* %17, align 4 call void @trace_integer(i32 %18) %19 = load %1** @pt, align 8 %20 = getelementptr inbounds %1* %19, i64 0, i32 2, i32 1 %21 = load i32* %20, align 4 call void @trace_integer(i32 %21) %22 = load %1** @pt, align 8 %23 = getelementptr inbounds %1* %22, i64 0, i32 0 -- edA-qa mort-ora-y -- -- -- -- -- -- -- --...

...rt-ora-y wrote: > Which optimizer would remove duplicate, or unneeded loads? In my > generator I end up having a lot of the same load. For example here I > keep loading "@pt" which will always be the same value. in order to do this, the optimizers need to know that the call to @trace_integer does not modify the contents of @pt. Is it logically possible for them to deduce this? If not, no optimizer can do what you want. Ciao, Duncan. > > %16 = load %1** @pt, align 8 > %17 = getelementptr inbounds %1* %16, i64 0, i32 2, i32 0 > %18 = load i32* %17, align 4 >...

...e in the optimized LLVM code. It appears that sometimes an inlined function is optimized though the function itself is not optimized to the same level. Below is an example of an unoptimized/non-inlined function call: define void @_entry() uwtable { entry: %0 = call i64 @eval_expr() call void @trace_integer(i64 %0) ret void } 'eval_expr' is a big ugly series of branches, so I'm very happy that LLVM figures it out and manages to optimize away the call entirely: define void @_entry() uwtable { entry: tail call void @trace_integer(i64 3) ret void } Obviously 'eval_expr' can...

On Oct 17, 2013, at 7:24 PM, edA-qa mort-ora-y <eda-qa at disemia.com> wrote: > On 17/10/13 23:57, Bill Wendling wrote: >> There shouldn't be any special linker flags you need to use. If >> you're getting segfaults, it's probably trying to access the data at >> an invalid location or something. Make sure that your EH table is >> properly aligned. You

On 17/10/13 23:57, Bill Wendling wrote: > There shouldn't be any special linker flags you need to use. If > you're getting segfaults, it's probably trying to access the data at > an invalid location or something. Make sure that your EH table is > properly aligned. You might want to hand calculate the values to make > sure that they're correct. What platform are you

Hi, On 11/04/13 06:06, edA-qa mort-ora-y wrote: > I have some exception handling which works fine using the JIT. Now I am > producing object files and linking them, but the exception handling > tables seem to be missing. I call _Unwind_RaiseException and get > _URC_END_OF_STACK as a result. you will get this if no catch clauses match (eg because there are no catch clauses, perhaps

...r %s3 } define void @main() { entry: %o = call %outer @eval_expr() %s = extractvalue %outer %o, 1 %s1 = extractvalue %inner %s, 0 ;ERROR: this value is 0.0, expected 1.5 call void @trace_float(double %s1) %s2 = extractvalue %inner %s, 1 ;ERROR: this value is 1073217536, expected 2 call void @trace_integer(i32 %s2) ret void } ; simple tracing functions @.int_str = private unnamed_addr constant [4 x i8] c"%d\0A\00" define void @trace_integer( i32 %i ) { entry: %sp = getelementptr [4 x i8]* @.int_str, i32 0, i32 0 call i32 (i8*, ...)* @printf(i8* %sp, i32 %i) ret void } @.float_str =...

I have some exception handling which works fine using the JIT. Now I am producing object files and linking them, but the exception handling tables seem to be missing. I call _Unwind_RaiseException and get _URC_END_OF_STACK as a result. I produce my object file using TargetMachine::addPassesToEmitFile and then I link my resulting files with: gcc -o prog input.o -fexceptions I'm sure I'm

On 24/02/13 09:02, Duncan Sands wrote: > in order to do this, the optimizers need to know that the call to > @trace_integer does not modify the contents of @pt. Is it logically > possible for them to deduce this? If not, no optimizer can do what > you want. Yeah, I thought about that and then realized in this context they could not (it's an external function). Is there some attribute I can mark the functi...

...IV on such integers fails, the below works: @a = global i200 undef @b = global i64 undef define void @_entry() { entry: store i200 200, i200* @a %0 = load i200* @a %1 = load i200* @a %2 = sdiv i200 %0, %1 %3 = trunc i200 %2 to i64 store i64 %3, i64* @b %4 = load i64* @b call void @trace_integer(i64 %4) ret void } Yet with a simple addition (the same SDIV) it fails: define void @_entry() { entry: store i200 200, i200* @a %0 = load i200* @a %1 = load i200* @a %2 = sdiv i200 %0, %1 %3 = trunc i200 %2 to i64 store i64 %3, i64* @b %4 = load i200* @a %5 = load i200* @a...