similar to: [LLVMdev] Variable-length Phi-node

On 9 Nov 2013, at 16:35, William Moses <moses.williamsteven at gmail.com> wrote: > Is it possible to create something which has the same effect of a variable-length phi node in the C++ api. Specifically, create a phi-node where the number of incoming values is not known at the time of its creation. The PHI node preallocates its storage, so no. > If there is no such way of creating a

You can call addIncoming(). /// addIncoming - Add an incoming value to the end of the PHI list /// void addIncoming(Value *V, BasicBlock *BB) { assert(V && "PHI node got a null value!"); assert(BB && "PHI node got a null basic block!"); assert(getType() == V->getType() && "All operands to PHI node must be the same

However, how would one allocate the buffer for a string if you did not know the length of the string at compile time? For instance, using the api how would one reproduce the code for the following c++ function? std::string add(std::string a, std::string b){ return a+b; } When allocating the buffer required for the new string, one can determine the length at runtime, however I do not know how

All, I am building my own language with llvm as the base. I was working on string concatenation (where a string is just an array of characters cast to a pointer to a character (i8*) ). Given two strings, it is possible to determine the length of new string by summing the number of characters until the null terminator and adding one. Unfortunately, I have no idea how to use the c-api to store

The toy language I've been playing around with represents all strings as a struct in llvm; struct string{ char *ptr; int str_len; int buffer_len; } And my AST has an interface like; String_AST{ int measure(); void copy(char *dest); struct string get_value(); } A constant string can be measured at compile time, for a string variable measure() just extracts str_len. Strings

Here is the code snippet that I am using to create the PHIs in the loop according to the PHIs in the new preheader. At this point I have already redirected the loop backedge and removed the preheader from the loop. for (BasicBlock::iterator II = loopHeaderBB->begin(); (PN=dyn_cast<PHINode>(II)); ++II) { // remove loop back PHI and add it to split BB

Hi, I'm incrementing my toy compiler to account for variable mutations around if/else blocks. Reading the Kaleidoscope tutorial, I've learnt that I can substitute the PHI node creation by allocas and retrieving the value later, if needed. The Kaleidoscope example seems to account for one value only, the result of: Value *ThenV = Then->Codegen(); (...) Value *ElseV =

I guess I thought that once I redirected the branches and created new PHIs that LLVM would correct the variable usage when I return true (changed CFG) from the pass. Is this not the case? On Wed, Mar 7, 2012 at 4:08 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Here is the code snippet that I am using to create the PHIs in the loop > according to the PHIs in the new preheader. At

I have attached a case of what I am trying to do, I'm pretty sure I'm just missing some simple API call. In the cfg you can see that although Im setting "lsr.iv441" as "lsr.iv44" from for.body.387.i it's not propagating that through the block or graph. On Wed, Mar 7, 2012 at 12:03 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > I am splitting a one BB

I am splitting a one BB loop into two BB. Basically, the one loop BB has 3 incoming values, one form back edge two from other edges. I want to extract the PHIs from the other two edges out into it's own BB and delete that from the loop, then redirect the backedge to the loopbody (non extracted portion) and create a new PHI coming from the extracted BB and the backedge. I can do this;

Hi, On Mon, May 1, 2017 at 8:47 AM, Daniel Berlin via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> Today, the IR requires that if you have multiple edges from A to B >> (typically with a switch) any phi nodes in B must have an equal number of >> entries for A, but that all of them must have the same value. > >> This seems rather annoying.... >> 1) It

On Feb 1, 2011, at 1:34 PM, Andrew Trick wrote: > On Feb 1, 2011, at 1:08 PM, Andrew Clinton wrote: > >> I have a (non-entry) basic block that contains only PHI nodes and an >> unconditional branch (that does not branch to itself). Is it always >> possible to merge this block with it's successor and produce a >> semantically equivalent program? I'm

Hi All,   Can we extract name of variable name from "MDNode" ?   1. Neither temp_MDNode->getName() nor temp_MDNode->getValueName() give me "global_int" which is name of a variable.   2. I tried below ways as well. DIVariable DV(mdnode1); Value *v = mdnode1->getOperand(0);//gives add 0x69   3. I have written below code to reach till variable name.        LLVMIname is

Closing this, found below links to get variable name.   http://groups.google.com/group/llvm-dev/browse_thread/thread/1a239f0d24db2b5c   http://markmail.org/message/fj5qg44vyjsdde7k#query:+page:1+mid:5zhmyncisenomcga+state:results           I could do following, to get the required information.                 const CallInst *CI = dyn_cast<CallInst>(Insn);                 int numoperands =

Here's what I've got so far - it seems to work, aside from the fact that DeleteDeadPHIs is not removing at least one dead PHI in my test program. --------------------- static bool mergeBlockIntoSuccessor(BasicBlock *pred, BasicBlock *succ) { if (succ == pred) return false; if (pred->getFirstNonPHI() != pred->getTerminator()) return false; //

¿Alguien sabe si el test de reacciones extremas de Moses está escrito en algún paquete de R? Gracias de antemano.

I have a new block with new PHI instructions. I addIncoming for the PHIs but this apparently doesn't update the use list, which I am trying to use later on to update any instructions who are no longer dominated. On Thu, Aug 2, 2012 at 2:55 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Thu, Aug 2, 2012 at 2:52 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > >

On 2017-01-20 14:31, Hal Finkel wrote: > > On 01/20/2017 06:11 AM, Jonas Paulsson via llvm-dev wrote: >> Hi, >> >> I wonder why getScalarizationOverhead() does not take into account >> the number of operands of the instruction? This should influence the >> number of extracts needed, so instead of >> >> Scalarization cost = NumEls * (insert +

Any ideas how I would go about writing specs for views which make use of content_for? I''d like, for example, to be able to specify that ABC view places XYZ in the sidebar, which I do using content_for(:sidebar). Am I missing something obvious? Kyle

Hi, I wonder why getScalarizationOverhead() does not take into account the number of operands of the instruction? This should influence the number of extracts needed, so instead of Scalarization cost = NumEls * (insert + extract) it would be better to do Scalarization cost = NumEls * (insert + (extract * numOperands)) / Jonas