search for: my_pragma

...andle new pragma inserted in the C/C++ source code and to adapt clang to transform them in metadata information. I want to keep this information until I run some passes on the *.bc files and manipulate the code. Then, I delete those "dummy" instructions. I want to transform this: #pragma my_pragma { C/C++ code C/C++ code } into LLVM_dummy_inst1 , !metadata_info !0 optimized LLVM code optimized LLVM code LLVM_dummy_inst2, !metadata_info !1 but if I run this with clang -O2 or with opt -O2, my dummy_inst are removed, so I cannot find the pragmas in the LLVM IR. I know that metadata will no...

...; "optimized LLVM code" block is better than trying to find artificial > barriers to communicate some info. > - > Devang > > Indeed, I want to use the metadata as barriers. They are meant to mark the beginning and the end of the compound statement of the pragma. #pragma my_pragma{ code } Therefore, I expect that the dummy-instructions will be part of different basic blocks, and I can determine the set of blocks in "code", inside the pragma region, from the control flow graph. So, if the instructions are reordered inside the same basic block, it will not pose an...

...in the C/C++ source code and to adapt > clang to transform them in metadata information. I want to keep this > information until I run some passes on the *.bc files and manipulate the > code. Then, I delete those "dummy" instructions. > I want to transform this: > #pragma my_pragma { > > C/C++ code > C/C++ code > } > > into > LLVM_dummy_inst1 , !metadata_info !0 > optimized LLVM code > optimized LLVM code > LLVM_dummy_inst2, !metadata_info !1 > > but if I run this with clang -O2 or with opt -O2, my dummy_inst are removed, > so I cann...

...tter than trying to find artificial >> barriers to communicate some info. >> - >> Devang >> >> > > Indeed, I want to use the metadata as barriers. They are meant to mark the > beginning and the end of the compound statement of the pragma. > > #pragma my_pragma{ > code > } > > Therefore, I expect that the dummy-instructions will be part of different > basic blocks, and I can determine the set of blocks in "code", inside the > pragma region, from the control flow graph. So, if the instructions are > reordered inside the sam...

Hello, Devang Patel wrote: > > > On Oct 25, 2010, at 12:09 PM, Xinfinity wrote: > >> #pragma my_pragma{ >> code >> } > >> I use a map >> (source_location, pragma) and I insert the dummy instruction when this >> location is reached in the code generator. It seems difficult to attach >> the >> metadata to the first and the last instruction emitted for the...

On Oct 25, 2010, at 2:13 AM, Xinfinity wrote: > > Hello, > > Does there exist something like a "dummy" instruction that is not removed by > the optimizers, even if it seems to be dead code? > I want to use such instructions to carry metadata information, but they > should have a minimal impact on the code generation and optimization. Use of metadata will not

On Oct 26, 2010, at 9:23 AM, Xinfinity wrote: > > Hello, > > > Devang Patel wrote: >> >> >> On Oct 25, 2010, at 12:09 PM, Xinfinity wrote: >> >>> #pragma my_pragma{ >>> code >>> } >> >>> I use a map >>> (source_location, pragma) and I insert the dummy instruction when this >>> location is reached in the code generator. It seems difficult to attach >>> the >>> metadata to the first and the l...

Hello, Does there exist something like a "dummy" instruction that is not removed by the optimizers, even if it seems to be dead code? I want to use such instructions to carry metadata information, but they should have a minimal impact on the code generation and optimization. I used an add instruction: %0 = add i8 1, 2, !pragma_instrument_mem_add !0 ; <i8> [#uses=0] which