similar to: [LLVMdev] AllocaInst for FunctionType?

Hi All, Has vmkit been updated and tested with LLVM 2.8? I am unable to build it (llvm builds fine). There were some errors with Makefile.rules: $(Verb) $(LLVMAS) -f $(<F) -o - | $(LLC) -march=cpp -cppgen=contents -o $@ (march and cppgen options not recognized). What I cannot get past is this one (the warnings concern me as well): ... make[3]: Leaving directory

hello Sean, On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote: > I'd really prefer this patch (series or single) is not accepted. This > will cause problems for everyone cherry-picking patches to a > downstream kernel (LTS or distro tree). I usually wouldn't expect > sympathy here, but the questionable benefit does not outweigh the cost > IM[biased]O. I agree that

hello Sean, On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote: > I'd really prefer this patch (series or single) is not accepted. This > will cause problems for everyone cherry-picking patches to a > downstream kernel (LTS or distro tree). I usually wouldn't expect > sympathy here, but the questionable benefit does not outweigh the cost > IM[biased]O. I agree that

On Thu, Jul 13, 2023 at 9:04?AM Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de> wrote: > > hello Sean, > > On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote: > > I'd really prefer this patch (series or single) is not accepted. This > > will cause problems for everyone cherry-picking patches to a > > downstream kernel (LTS or distro tree). I

On Thu, Jul 13, 2023 at 9:04?AM Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de> wrote: > > hello Sean, > > On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote: > > I'd really prefer this patch (series or single) is not accepted. This > > will cause problems for everyone cherry-picking patches to a > > downstream kernel (LTS or distro tree). I

This patch removes the deprecated form of FunctionType::get() which takes "const Type*"s for the argument types, and replaces just enough "const Type*" with "Type*" elsewhere to get everything building cleanly again. (My motivation for this was that I was getting ambiguous overload errors from some calls to FunctionType::get() in the Clang source.) Chris, are you

Sure, go for it. FWIW, I was waiting to do this (eventually "const Type" will just be "Type" everywhere). I have a long list of cleanups that I want to land after the branch lands... but I was waiting for after the branch lands to make merging it less annoying and make things more incremental. Unfortunately I'm struggling to find time to finish things up and land the

On Sun, Nov 18, 2012 at 6:40 AM, edA-qa mort-ora-y <eda-qa at disemia.com> wrote: > This may sound weird, but what exactly is a FunctionType? That is, in > terms of memory, or underlying value, what does the FunctionType > actually represent. At first I though it might be a pointer, but it is > not -- since you have to wrap a PointerType around it to use as such. > Can a

On 18/11/12 18:37, David Blaikie wrote: > Types, function or otherwise, have no in-memory representation. They > merely describe how bits should be interpreted. This is what I'm asking about the FunctionType. If I have a Pointer to a FunctionType it is clear how the bits should be interpreted, but what does the FunctionType it self say about the bits, if anything? In terms of use, can

On 2/28/11 6:31 AM, Gabriel Rodríguez wrote: > Hi all, > > I am trying to extend a FunctionType to include new parameters. In > particular, I want to > ensure that the main function has been declared with both argsc and > argsv. However > there seems to be no easy way to accomplish this: > llvm::Function::getFunctionType() returns a > a reference to a const object,

This may sound weird, but what exactly is a FunctionType? That is, in terms of memory, or underlying value, what does the FunctionType actually represent. At first I though it might be a pointer, but it is not -- since you have to wrap a PointerType around it to use as such. Can a FunctionType value actually exist, or is strictly an abstract concept? In particular, can I actually directly define

Just a note: I just checked in a change that corrects some very non-intuitive behavior of the AllocaInst & MallocInst classes. Before, the constructor would take a Type which would specify the return type of the instruction, instead of the operand type. Now it takes the operand type directly. More concretely: LLVM Code: X = alloca int ; int* Y = malloc int * ; int** Old C++

I remember reading in a previous thread by Chris that all instructions will have the "instruction to insert before" as an argument to their constructors. In the code I have, this hasn't been done for the AllocaInst. I did a recent "cvsupdate", but the code still hadn't changed. Has this code already been updated ? If not, I request that it be updated as soon as

> AllocaInst. I did a recent "cvsupdate", but the code still hadn't > changed. Has this code already been updated ? If not, I request that it > be updated as soon as possible, as it simplifies our implementation of > MP1 (we need to insert the alloca's at the beginning of the function). The plan is to update the CSIL CVS tree soon. When that happens you should get

Hello all When using llvm-ld to link several bitcode files produced by LLVM-GCC, I ran into the problem that the resulting linked file had missing dbg entries for AllocaInst values. After some digging I found that llvm::MapValue returns NULL when it encounters an AllocaInst. The attached trivial patch fixes the problem. Is this behaviour intended? Regards, Jacob -- Jacob Zimmermann Oracle

Hello, I have the following problem: I need to allocate an array. I know it's size - it's constant (ConstExpr), but my problem is that I know it only during the runtime (i.e for every variable I'm trying to allocate an array equal to size of a variable). As I understand I can't do it, since it's possible to initialize ArrayType only if I know it's size in integer units.

Hello, Hopefully this is the correct place for this sort of question. I have been trying to do some simple instrumentation of LLVM IR, and I have been confused by the return type of alloca. When passing an AllocaInst as a parameter to a function call, the parameter type is i32**, which is not what I would expect. Really I would like the address of the allocated memory. What am I missing? And is

Hi, For the following code const Type * Int32Type = IntegerType::getInt32Ty(getGlobalContext()); AllocaInst* newInst = new AllocaInst(Int32Type, 0, "flag", Bb); Bb->getInstList().push_back(newInst); It gives me the error " error: no matching constructor for initialization of 'llvm::AllocaInst' AllocaInst* newInst = new

You need a pointer-to-function type, but FunctionType just gives you a function type. Use PointerType::getUnqual(FunctionType::get(...)). Or TypeBuilder<char (*func)(void*), false>::get(context) from Support/TypeBuilder.h. On Mon, Nov 29, 2010 at 10:37 AM, Salomon Brys <salomon.brys at gmail.com>wrote: > Hi all. > I would like to declare a function that takes a function pointer

Hi all, I am trying to extend a FunctionType to include new parameters. In particular, I want to ensure that the main function has been declared with both argsc and argsv. However there seems to be no easy way to accomplish this: llvm::Function::getFunctionType() returns a a reference to a const object, while modifying only the argument list yields an error during verification since the