search for: frameaddress

+nlewycky On Mon, Nov 17, 2014 at 9:36 AM, Volodymyr Kuznetsov <vova.kuznetsov at epfl.ch > wrote: > Hi Kostya, > > On Sat, Nov 15, 2014 at 1:53 PM, Volodymyr Kuznetsov < > vova.kuznetsov at epfl.ch> wrote: > > Do you think moving the pass to lib/Transform/Instrumentation but > > scheduling it during code generation would make sense ? If so, we'll >

...to using normal allocas and "blessing" each of them as escaped allocations that can be referenced from EH helpers. Here's what it would look like: define i32 @parent() { %a = alloca i32 %b = alloca i32 call void (...)* @llvm.frameescape(i32* %a, i32* %b) %fp = call i8* @llvm.frameaddress(i32 0) call void @helper_func(i8* %fp) %a_val = load i32, i32* %a %b_val = load i32, i32* %b %r = add i32 %a_val, %b_val ret i32 %r } define void @helper_func(i8* %fp) { %a.i8 = call i8* @llvm.framerecover(i8* bitcast (i32 ()* @parent to i8*), i8* %fp, i32 0) %b.i8 = call i8* @llvm.f...

Hi all, I have recently encountered a problem when creating LLVM IRs. I am wondering if there is a standard or easy way to create a load from a certain register? For example, CreateLoad(rbp, NAME). Thanks, Chen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131213/ec277276/attachment.html>

...dering > if there is a standard or easy way to create a load from a certain register? > For example, CreateLoad(rbp, NAME). LLVM doesn't directly provide access to any machine registers. If you want %rbp because it's the frame pointer then for that one case there is actually an @llvm.frameaddress intrinsic you can call to get it. But if you want other registers as well, the only way I can think of is through inline assembly. This is roughly the line clang produces, and should be sufficient: %my_value = call i64 asm "movq $0, %rbp", "=r"() Cheers. Tim.

I'm getting a 'function arguments must be value types' assertion from the following (abridged) code. Basically, I'm writing a pass that inserts llvm.frameaddress intrinsic calls everywhere 'interesting' that passes on the result by calling the C function void mcp_trace_stack(char *ptr). First I grab the functions themselves: Constant *MCPTraceStack, *LLVMFrameAddress; std::vector<const Type*> argstype; argstype.push_back(Point...

...; > program by using LLVM. > > I am trying to add some new intrinsic functions after each "alloca" in > > bitcode. Is it a good way to do it? > > Any existing tools can help me to do so? > > Depending on how much precision you need, you could use the > llvm.frameaddress intrinsic. Chris: This prompts me to a related question. For procedures that do not call alloca() at run time, is there a way to learn the stack frame size in bytes for each procedure at static compile time? shap

...s escaped allocations that can be referenced from EH helpers. Here's > what it would look like: > > > > define i32 @parent() { > > %a = alloca i32 > > %b = alloca i32 > > call void (...)* @llvm.frameescape(i32* %a, i32* %b) > > %fp = call i8* @llvm.frameaddress(i32 0) > > call void @helper_func(i8* %fp) > > %a_val = load i32, i32* %a > > %b_val = load i32, i32* %b > > %r = add i32 %a_val, %b_val > > ret i32 %r > > } > > > > define void @helper_func(i8* %fp) { > > %a.i8 = call i8* @llvm.fram...

...o what it was inside foo before transferring control back to foo (bar's stack frame is not disposed of). We'd make sure that foo only accesses local variables via FP (SP addressing is disabled). What we'd like to do is something like (abstracted syntax and semantics :-) (FP) = @llvm.frameaddress(1) ; So, is there a portable way to change FP? -- Salvador Abreu -- http://www.di.uevora.pt/~spa/ Departamento de Informatica Universidade de Evora - PORTUGAL

Dear All, Does anyone have good ideas to dynamically measure the stack size of a program by using LLVM. I am trying to add some new intrinsic functions after each "alloca" in bitcode. Is it a good way to do it? Any existing tools can help me to do so? Any help will be deeply appreciated. Thank you, GUanhua -------------- next part -------------- An HTML attachment was scrubbed...

...lly measure the stack size of a > program by using LLVM. > I am trying to add some new intrinsic functions after each "alloca" in > bitcode. Is it a good way to do it? > Any existing tools can help me to do so? Depending on how much precision you need, you could use the llvm.frameaddress intrinsic. -Chris -- http://nondot.org/sabre/ http://llvm.org/

...exposes this information in a framework suitable > > for emitting metadata tables from a compiler plugin, if your interest > > lies in that direction. > > That too, but my immediate interest was computing an upper bound on > stack size for the Coyotos kernel. Does 'llvm.frameaddress' work for this purpose? Have you tried it? It seems 'llvm.frameaddress' is not very precise. Is it possible to compute the upper bound of stack size in bits? Many thanks, GUan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/...

...work). - Operations that don't need to work with iptr - i.e. I don't mind having to convert to some other int type first: - switch - extractelement / insertelement / shufflevector - extractvalue / insertvalue - not sure about these. - code generator intrinsics (frameaddress, etc.) - Converting to pointer types: inttoptr and ptrtoint should be no-ops, effectively. - Converting to other integer types: The issue here is that with other integer conversions in LLVM, you are required to know whether or not you are converting to a larger or smaller size - whet...

...re is an example: %160 = add i64 %158, %159 ; <i64> [#uses=1] %161 = sub i64 %160, %startHash.0 ; <i64> [#uses=5] tail call void asm sideeffect "", "~{dirflag},~{fpsr},~{flags},~{memory}"() nounwind %fp73 = call i8* @llvm.frameaddress(i32 0) ; <i8*> [#uses=1] %sp74 = call i8* @llvm.stacksave() ; <i8*> [#uses=1] call fastcc void @Function1(i8* %sp74, i8* %fp73) nounwind %162 = call i32 (i32, ...)* @Function2(i32 0) ; <i32> [#uses=1] tail call void asm sideeffect "", "~{di...

...ds reasonable. > Operations that don't need to work with iptr - i.e. I don't mind > having to convert to some other int type first: > switch > extractelement / insertelement / shufflevector > extractvalue / insertvalue - not sure about these. > code generator intrinsics (frameaddress, etc.) insert/extractvalue need to work, as does load/store/phi for it to be a useful first class value. switch should "just work". I don't have an opinion about whether intptr should work with vectors, but it seems sensible either way. I agree about frameaddress. > Conve...

On Nov 10, 2009, at 4:10 PM, Talin wrote: > I realize that most users of LLVM aren't affected by this, because most frontends aren't target-neutral, and thus know in advance how big a pointer is. At least, that's my impression. I believe that. > There's only a tiny handful of fairly esoteric cases which require selecting a target before you generate IR. Unfortunately, the

...#39;t you use the same > shadow-memory scheme here as you do for heap accesses (especially > considering that escaped stack addresses will be counted this way > anyway), and then upon function exit, collect the counts from the > local stack? I think the necessary region is: > [@llvm.frameaddress(0), @llvm.frameaddress(0) + > @llvm.get.dynamic.area.offset()) > or you can call @llvm.stacksave() upon entry and use that as the base > offset. > -Hal > > There is one simple improvement we may want to explore: the > > temporal > > locality of struct field accesses...

...erring > control back to foo (bar's stack frame is not disposed of). > > We'd make sure that foo only accesses local variables via FP (SP > addressing is disabled). > > What we'd like to do is something like (abstracted syntax and semantics > :-) > (FP) = @llvm.frameaddress(1) ; > > So, is there a portable way to change FP? > > -- > Salvador Abreu -- http://www.di.uevora.pt/~spa/ > Departamento de Informatica > Universidade de Evora - PORTUGAL > > > > _______________________________________________ > LLVM Developers mailing l...

Misha Brukman wrote: > >>1. Opcodes and intrinsics >> > That's not really correct. The intrinsics such as llvm.frameaddress and > llvm.returnaddress have no equivalents in LLVM opcodes -- the meaning of > the intrinsics is specifically machine-dependent, and LLVM (and its > opcodes) are machine-independent, so there is no valid interchange of > these intrinsics with any combination of LLVM opcodes. > Ye...

...ategories. I'm excluding here externally-defined terms (e.g. llvm.va_start): No separators (except for the initial namespace prefix): @llvm.gcroot @llvm.gcread @llvm.gcwrite @llvm.experimental.stackmap @llvm.experimental.patchpoint @llvm.experimental.gc.statepoint @llvm.returnaddress @llvm.frameaddress @llvm.localescape @llvm.localrecover @llvm.stacksave @llvm.stackrestore @llvm.pcmarker @llvm.readcyclecounter @llvm.bitreverse @llvm.eh.begincatch @llvm.eh.endcatch @llvm.eh.padparam @llvm.stackprotector @llvm.stackprotectorcheck @llvm.objectsize @llvm.donothing Words with dots: @llvm.sad...

Please reference the prior RFC on EfficiencySanitizer. This is one of the performance analysis tools we would like to build under the EfficiencySanitizer umbrella. ==================== Motivation ==================== An application is running sub-optimally if only part of the data brought into the cache is used, which we call cache fragmentation. Knowing the cache fragmentation information