similar to: [LLVMdev] Changing Alignment Attribute using New Attribute API

> On 24 Mar 2015, at 14:55, Aaron Ballman <aaron at aaronballman.com> wrote: > > On Tue, Mar 24, 2015 at 9:48 AM, Rinaldini Julien > <julien.rinaldini at heig-vd.ch> wrote: >> Hi, >> >> I want to *tag* some functions with some *flags*. I was using annotate((“myFlag”)) and everything was working fine until I tried on ObjC method. It seems that clang just

These were requested by Bill Wendling to simplify a Mips 16 clang change. The test is in the code in Clang which uses these for mips 16. -------------- next part -------------- Index: include/llvm/IR/Function.h =================================================================== --- include/llvm/IR/Function.h (revision 176874) +++ include/llvm/IR/Function.h (working copy) @@ -181,6 +181,14 @@

Hi, all, I managed to insert the assertion in my bytecode, but the result is not really what I expected :( Let me do a quick recap: I am trying to instrument the bytecode with some assertions, and to do this, I want to insert the abort() function into the bytecode. The problem is that LLVM is creating a new abort() function, instead of using the one that already exists in libc. Let me

On Nov 20, 2012, at 11:03 AM, Meador Inge <meadori at codesourcery.com> wrote: > On Nov 13, 2012, at 12:20 AM, Bill Wendling wrote: > >> IR Changes >> ---------- >> >> The attributes will be specified within the IR. This allows us to generate code >> that the user wants. This also has the advantage that it will no longer be >> necessary to specify

Victor Campos wrote: > Guys, > > I would like to instrument the bytecode that LLVM produces with > assertions. I have written the instrumentation code manually, but I do > not know how to halt the program in case the assertion is false. I took > a look into the bytecode that LLVM produces for a program like: > > #include <stdlib.h> > int main() { >

On 08/24/2017 09:40 AM, Tim Northover wrote: > On 17 August 2017 at 15:15, Rodney M. Bates via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> For an indirect call, i.e., on a function whose address is runtime variable, >> I can't find any place/way to attach this attribute. LLVMAddAttribute >> won't take a type. > > In the C++ API you'd add the

On 5/15/13 10:27 AM, Ralf Karrenberg wrote: > Hi, > > I am again struggling to find my way around the Attribute classes. > What I want to do is clone a function into a declaration where some > parameters may have a different alignment. > CloneFunctionInto in debug mode hits an assertion which is marked with > a FIXME (Attributes.cpp:673). > I would be totally fine with

Hi John, thanks for the pointer. However, I'd rather avoid rolling a custom implementation. After all, it's not like I want to do something drastically different... I had sorted out the problem for 3.2 as well as a previous version of 3.3 trunk, but the API changed about a hundred times. Now as it apparently has stabilized, I moved to a the 3.3 release branch just to find that even

I wanted to mention that I'm planning to start writing and sending out patches for this. Naming the attribute 'alloca' was really confusing, so I'd like to change it to 'inalloca', which follows the preposition pattern of inreg and byval. After discussion, we decided it was silly to add stackbase uses to alloca instructions. They should stay simple. Instead, we'll

Now, I am using LLVM-3.3 do some process with functions, however there are some difficult things I can't handle by myself. So, I want get your help to get it down properly. Q1. There is a function declaration: call i32 @create(i64* %tid, %union.t* %pab, i8* (i8*)* @worker, i8* null) // callInst Store instruction goes like this: store i8* (i32, double, i32*)* %fp, i8* (i32, double, i32*)**

Guys, I would like to instrument the bytecode that LLVM produces with assertions. I have written the instrumentation code manually, but I do not know how to halt the program in case the assertion is false. I took a look into the bytecode that LLVM produces for a program like: #include <stdlib.h> int main() { exit(1); } And it is like this: define i32 @main() nounwind { entry:

LLVM developers, I was wondering if the program would still be safe if I strip the byval attributes from the parameters in the entire bitcode. LLVM language reference manual states that "The attribute implies that a hidden copy of the pointee is made between the caller and the callee, so the callee is unable to modify the value in the callee. This attribute is only valid on LLVM pointer

Hi Tim, Correction to my last email. What I should have said is that the new pointer is used by the callee rather than the original byVal pointer arg. (the byVal pointer arg remains but is not used by the callee). viz: define void @f1(%struct.tag* byval) { entry: %st = alloca %struct.tag, align 4 %1 = bitcast %struct.tag* %st to i8* %2 = bitcast %struct.tag* %0 to i8* call void

Hi Robert, suppose you have a "byval" argument with type T*, and the caller passes a T* called %X for it, while in the callee the argument is called %Y. The IR level semantics are: (1) a copy should be made of *%X. Whether the callee or the caller makes the copy depends on the platform ABI. (2) in the callee, %Y refers to the address of this copy. There are many ways (1) can be

Duncan Sands wrote: > Hi, byval means that the parameter setup code for performing a call > copies the struct onto the stack, in an appropriate position relative > to the other call parameters. > > >> I'm particularly confused by the "between the caller and the callee" part. The >> way I see this, the responsibility for the copying should be with either

Hi, byval means that the parameter setup code for performing a call copies the struct onto the stack, in an appropriate position relative to the other call parameters. > I'm particularly confused by the "between the caller and the callee" part. The > way I see this, the responsibility for the copying should be with either the > caller or the callee, It is with the caller.

Dear LLVM developers, Our team has developed an LLVM-based protection mechanism that (i) prevents control-flow hijack attacks enabled by memory corruption errors and (ii) has very low performance overhead. We would like to contribute the implementation to LLVM. We presented this work at the OSDI 2014 conference, at several software companies, and several US universities. We received positive

I missed that the testing case is returning a struct. You are right in VARegSaveSize. For callee: sub sp, sp, #16 push {r11, lr} mov r11, sp sub sp, sp, #8 str r3, [r11, #20] str r2, [r11, #16] str r1, [r11, #12] ldr r1, [r11, #76] The beginning of the input struct @ sp_at_entry - 16 - 8 + 12 = sp_at_entry -12 # of leftover bytes 67-12 = 55 r11+76 is @ sp_at_entry - 24 + 76 = sp_at_entry

Hi Reid, On 25/07/13 23:38, Reid Kleckner wrote: > Hi LLVM folks, > > To properly implement pass-by-value in the Microsoft C++ ABI, we need to be able > to take the address of an outgoing call argument slot. This is > http://llvm.org/PR5064 . > > Problem > ------- > > On Windows, C structs are pushed right onto the stack in line with the other > arguments. In

Hi, Thanks for the help. I tried this out, but on x86_64 and with llvm 2.6 and llvm-gcc 4.2.1, I dont seem to get an aligned variable. This is the function definition that I have define internal fastcc void @walksub(%struct.hgstruct* noalias nocapture sret %agg.result, %struct.node* %p, double %dsq, %struct.hgstruct* byval align 64 %hg, i32 %level) nounwind { And these are the call sites,