search for: d72475

Displaying 3 results from an estimated 3 matches for "d72475".

Did you mean: 372475
2020 Jan 14
3
Alignment parameter attributes
"Doerfert, Johannes via llvm-dev" <llvm-dev at lists.llvm.org> writes: > We could use a custom tag on `llvm.assume`, as an extension of > https://reviews.llvm.org/D72475, but that is not yet implemented. I had thought about using llvm.assume but was wondering if there is a better way. Tagging the loads with metadata really seems about the same amount of effort. Both require major surgery to code generation. Thanks for your help Johannes! -Dav...
2020 Jan 14
2
Alignment parameter attributes
I have a question about how to communicate alignment via function parameters. The IR supports an attribute specifying the alignment of a pointer parameter: define void @func(double* noalias align 64 %p) This says that %p is 64-byte aligned. Great! Is there any way to convey the alignment of a pointer pointed to by a ** argument? I'd like something like this: define void @func(double*
2019 Dec 16
7
[RFC] How to manifest information in LLVM-IR, or, revisiting llvm.assume
Abstract: It is often hard or impossible to encode complex, e.g., non-boolean, information in an `llvm.assume(i1)`. This RFC describes various problems we have right now and provides alternative design ideas. Some Existing Problems: A) The boolean requirement. The current `llvm.assume(i1)` expects a boolean that is known to hold true at runtime (once the `llvm.assume` call is reached).