search for: eh_typeid_for

...t; the type and >> decode the structure using DWARF information. Currently we have two >> problem >> needs to solve: >> >> 1. Dwarf information generated by BPF backend lost all DW_AT_name field; >> >> 2. How to get typeid from local variable? I tried llvm.eh_typeid_for >> but it support global variable only. >> >> Following is my response to Alexei. >> >> On 2015/8/4 3:44, Alexei Starovoitov wrote: >>> On 7/31/15 3:18 AM, Wangnan (F) wrote: >>> >> >> [SNIP] >> >>> didn't have time t...

...ill get type information? I thought type is > meaningful in frontend only, and backend behaviors is unable to affect > DWARF generation, right? why do we need to affect type generation? we just need to know dwarf type id in the backend, so we can emit it as a constant. I still think lowering eh_typeid_for differently may work. Like instead of doing GV = ExtractTypeInfo(I.getArgOperand(0)) followed by getMachineFunction().getMMI().getTypeIDFor(GV) we can get dwarf type id from I.getArgOperand(0) if it's any pointer to struct type. I'm not familiar with dwarf handling part of llvm, but feels p...

...anism to check to see if we’ve already outlined the handler at the specified start block (which handles the case of handlers shared between landing pads) and if not starts the outlining process at that block. For cleanup handlers I’m treating any catch dispatch block (identified by looking for the eh_typeid_for+cmp+conditional branch pattern) as a stopping point for the cloning process. Here’s a snippet of comments explaining how I am doing the block mapping. // The landing pad sequence will have this basic shape: // // <cleanup handler> // <selector comparison> // <catch handler> /...

On 8/4/15 11:51 PM, Wangnan (F) wrote: > void bpf_store_half(void *skb, int off, int val) > asm("llvm.bpf.store.half"); > int func() > { > bpf_store_half(0, 0, 0); > return 0; > } > > Compiled with: > > $ clang -g -target bpf -O2 -S -c test.c > > And get this: > > .text > .globl func > .align

...anism to check to see if we’ve already outlined the handler at the specified start block (which handles the case of handlers shared between landing pads) and if not starts the outlining process at that block. For cleanup handlers I’m treating any catch dispatch block (identified by looking for the eh_typeid_for+cmp+conditional branch pattern) as a stopping point for the cloning process. Here’s a snippet of comments explaining how I am doing the block mapping. // The landing pad sequence will have this basic shape: // // <cleanup handler> // <selector comparison> // <catch handler> /...