search for: lowerintrinsiccall

...ber and types of args were incompatible. Every samples/bpf/sockex[0-9]_kern.c is using llvm.bpf.load.* intrinsics. the typeid changing ids with order is surprising. I think the assertion in ExtractTypeInfo() is not hard. Just there were no such use cases. May be we can do something similar to what LowerIntrinsicCall() does and lower it differently in the backend.

...insics. stores, so far, are done via single bpf_store_bytes() helper function. > >the typeid changing ids with order is surprising. > >I think the assertion in ExtractTypeInfo() is not hard. > >Just there were no such use cases. May be we can do something > >similar to what LowerIntrinsicCall() does and lower it differently > >in the backend. > > > But in backend can we still 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 ne...

Hello, I can see the occurrences of several LLVM intrinsic functions in the LLVM IR generated by llvm-dis disassembler. Is there any means to rewrite these functions reliably using basic LLVM IR statements? -- Thanks & Regards, Dipanjan -------------- next part -------------- An HTML attachment was scrubbed... URL:

...as via llvm-dev wrote: >> Hello, >> >> I can see the occurrences of several LLVM intrinsic functions in the LLVM >> IR generated by llvm-dis disassembler. Is there any means to rewrite these >> functions reliably using basic LLVM IR statements? > > You can use `LowerIntrinsicCall` from "llvm/CodeGen/IntrinsicLowering.h" > to do so. This will lower intrinsics to (target-specific) function calls that implement the underlying functionality, which is almost certainly not what you want to do. The question doesn’t really make sense. Intrinsics *are* ‘basic LLVM IR...

Dear LLVM-Mailing list, I have a beginners question again - please don't be mad at me! I was playing around with llvm::Module instance and ended in iterating over all global values and functions. I then noticed the function "llvm.memcpy". As I understood, this is an intrinsic coming from the LLVM. So far so good! I then emitted an object file with the llvm::ExecutionEngine and

...r the single-thread lowering is to be able to run code that uses these intrinsics in the KLEE symbolic execution engine but I imagine it could have other uses such as a whole-program LTO that lowers atomic operations to more efficient non-atomic operations when it is known to be safe to do so. The LowerIntrinsicCall method would need to be refactored into multiple methods I think, but I'm not sure about the granularity. Do we need more than standard and single-thread? Thanks, -- Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Support-for-lowering-atomic-intr...

Hi all, I've now got my LLVM-based model checker more or less working, but I'm seeing something a bit strange happening. As you may remember, I started with the lli code and extended it considerably. I have retained something that looks vaguely like the original ExecutionContext stack, though I now have one stack per thread, and the whole data structure is implemented with custom

...an intrinsic that maps directly to a single machine instruction, and a more complex intrinsic that invokes a C function. In particular, I tried adding: def int_test_and_clear_bit : X86Inst; to the end of X86.td, but that resulted in a tablegen compilation error. Code I've added to the end of LowerIntrinsicCall in /lib/CodeGen/IntrinsicLowering.cpp: ----------------- case Intrinsic::test_intrinsic: break; ----------------- Note that the intent is to make this intrinsic a NOOP, just as an experiment. But alas, the following trivial test program does not work: ----------------- #include <stdio...

...onPasses, PerModulePasses and CodeGenPasses pass managers and then runs them. Assuming you did add some special passes to check for problems, wouldn't those passes have to duplicate a lot of effort in some cases to find the answers? Take for example the existing warnings in IntrinsicLowering::LowerIntrinsicCall. Those badly need to be cleaned up. Would clang run a special pass to check for intrinsics that are not supported by the target? That pass would need to be implemented as part of clang so that it would have access to clang's diagnostic machinery, but it would also need to know details about...

...onPasses, PerModulePasses and CodeGenPasses pass managers and then runs them. Assuming you did add some special passes to check for problems, wouldn't those passes have to duplicate a lot of effort in some cases to find the answers? Take for example the existing warnings in IntrinsicLowering::LowerIntrinsicCall. Those badly need to be cleaned up. Would clang run a special pass to check for intrinsics that are not supported by the target? That pass would need to be implemented as part of clang so that it would have access to clang's diagnostic machinery, but it would also need to know details about...

...onPasses, PerModulePasses and CodeGenPasses pass managers and then runs them. Assuming you did add some special passes to check for problems, wouldn't those passes have to duplicate a lot of effort in some cases to find the answers? Take for example the existing warnings in IntrinsicLowering::LowerIntrinsicCall. Those badly need to be cleaned up. Would clang run a special pass to check for intrinsics that are not supported by the target? That pass would need to be implemented as part of clang so that it would have access to clang's diagnostic machinery, but it would also need to know details about...

...onPasses, PerModulePasses and CodeGenPasses pass managers and then runs them. Assuming you did add some special passes to check for problems, wouldn't those passes have to duplicate a lot of effort in some cases to find the answers? Take for example the existing warnings in IntrinsicLowering::LowerIntrinsicCall. Those badly need to be cleaned up. Would clang run a special pass to check for intrinsics that are not supported by the target? That pass would need to be implemented as part of clang so that it would have access to clang's diagnostic machinery, but it would also need to know details about...

Send again since llvmdev is moved to llvm-dev at lists.llvm.org On 2015/8/5 9:58, Wangnan (F) wrote: > > > On 2015/8/4 17:01, Wangnan (F) wrote: >> For people who in llvmdev: >> >> This mail is belong to a thread in linux kernel mailing list, the >> first message >> can be retrived from: >> >> http://lkml.kernel.org/r/55B1535E.8090406 at

On Tue, Jul 16, 2013 at 9:34 PM, Bob Wilson <bob.wilson at apple.com> wrote: > > On Jul 16, 2013, at 5:51 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > > On Tue, Jul 16, 2013 at 5:21 PM, Quentin Colombet <qcolombet at apple.com> > wrote: > > ** Advices Needed ** > > 1. Decide whether or not we want such capabilities (if we do not we may >

On Jul 16, 2013, at 5:51 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Tue, Jul 16, 2013 at 5:21 PM, Quentin Colombet <qcolombet at apple.com> wrote: >> ** Advices Needed ** >> >> 1. Decide whether or not we want such capabilities (if we do not we may just >> add sporadically the support for a new warning/group of warning/error). >> 2. Come