similar to: [LLVMdev] BasicBlock succ iterator

Displaying 15 results from an estimated 15 matches similar to: "[LLVMdev] BasicBlock succ iterator"

2011 Oct 13
0
[LLVMdev] BasicBlock succ iterator
thank john, i have used dump() , and each blocks had pred except entery block, i get the following output: fun main entry entry: %retval = alloca i32 %0 = alloca i32 %i = alloca i32 %j = alloca i32 %a = alloca [2 x i32] %n = alloca i32 %t = alloca i32 %"alloca point" = bitcast i32 0 to i32 %1 = getelementptr inbounds [2 x i32]* %a, i32 0, i32 0 %2 = load i32*
2011 Oct 14
0
[LLVMdev] BasicBlock succ iterator
Hi I have checked all blocks, each block have a Terminator instruction and each blocks belongs to a function. I'm really confused. I guess the problem is caused by the removal of the Loop,The code is as follows: * //every block to header (except the ones in the loop), will now redirect to newblock for (pred_iterator PI = pred_begin(header); PI != pred_end(header); ++PI) {
2015 Mar 03
2
[LLVMdev] RFC: Better alternative to llvm.frameallocate for use in Windows EH
I realized that WinEH preparation can probably be a lot less invasive than it is currently. Initially, when I was thinking about recovering the address of an object in a parent stack frame, I thought about it in terms of "let's allocate something at a fixed offset from ebp to keep things simple". That line of thinking suggested that we needed this thing to be fundamentally different
2020 Apr 16
2
[RFC] [Windows SEH][-EHa] Support Hardware Exception Handling
As stated in the design paragraph, this design does not intend to model precise CFG at instruction level since it’s complicated and unnecessary. As long as we comply C and C++ rules listed below, we achieve -EHa semantic. There is NO need to precisely model HW exception control flow at instruction-level. Your example about memcpy() is just a bug in current implementation. I will fix it so that
2015 Mar 04
2
[LLVMdev] RFC: Better alternative to llvm.frameallocate for use in Windows EH
On Wed, Mar 4, 2015 at 12:36 AM, John McCall <rjmccall at apple.com> wrote: > > On Mar 3, 2015, at 2:25 PM, Reid Kleckner <rnk at google.com> wrote: > > > > I realized that WinEH preparation can probably be a lot less invasive > than it is currently. > > > > Initially, when I was thinking about recovering the address of an object > in a parent stack
2020 Apr 16
2
[RFC] [Windows SEH][-EHa] Support Hardware Exception Handling
Hi, Eli, Why are you under the impression that threw_exception() will not be called if optimizations are enabled? I don’t know if the -EHa Spec is clearly described in MSFT Webs. At least this proposal has described the rules for both C & C++ code. The very first rule clearly said that “no exception can move in or out of _try region., i.e., no potential faulty instruction can be moved
2010 Jun 11
3
Calculation of r squared from a linear regression
Hi, I'm trying to verify the calculation of coefficient of determination (r squared) for linear regression. I've done the calculation manually with a simple test case and using the definition of r squared outlined in summary(lm) help. There seems to be a discrepancy between the what R produced and the manual calculation. Does anyone know why this is so? What does the multiple r squared
2023 Mar 11
1
Multiple Assignment built into the R Interpreter?
There are some other considerations too (apologies if these were mentioned above and I missed them). Also below are initial thoughts, so apologies for any mistakes or oversights. For example, if [a, b] <- my2valuefun() works the same as local({ tmp <- my2valuefun() stopifnot(is.list(tmp) && length(tmp) == 2) a <<- tmp[[1]] b <<- tmp[[2]] }) Do we expect [a[1], b[3]]
2023 Mar 11
3
Multiple Assignment built into the R Interpreter?
Thanks Duncan and Ivan for the careful thoughts. I'm not sure I can follow all aspects you raised, but to give my limited take on a few: > your proposal violates a very basic property of the language, i.e. that all statements are expressions and have a value. > What's the value of 1 + (A, C = init_matrices()). I'm not sure I see the point here. I evaluated 1 + (d =
2011 Oct 05
2
[LLVMdev] replacing a global variable by a constant
hi i want replacing a global variable by a constant value for erase instruction. i had seen the code that as follows for (llvm::GlobalVariable::use_iterator U = gv->use_begin(); U != gv->use_end();--U ) { llvm::Instruction *I = llvm::cast<llvm::Instruction>(U); I->replaceAllUsesWith(constPtr); I->eraseFromParent(); } but i dont know how can declare constptr.
2011 Oct 05
0
[LLVMdev] replacing a global variable by a constant
Hi nada, > i want replacing a global variable by a constant value for erase instruction. I'm not sure what you mean exactly. A GlobalVariable has pointer type. Do you want to replace that pointer by a constant pointer? Or is it rather that you want to say that the contents of the memory pointed to by the GlobalVariable is constant, and have all places that load that GlobalVariable
2011 Oct 06
1
[LLVMdev] replacing a global variable by a constant
I would delete the Loop. I used the following code. cout << "begin to delete loop" << endl; for (Loop::block_iterator bi = L->block_begin(), bi2; bi != L->block_end(); bi = bi2) { bi2 = bi; bi2++; BasicBlock * BB = *bi; for (BasicBlock::iterator ii = BB->begin(), ii2; ii != BB->end(); ii= ii2) { ii2 = ii;
2015 Jan 08
2
[LLVMdev] JIT simple module and accessing the value fails
I'm using the llvm-c API and want to use the JIT. I've created the following module ; ModuleID = '_tmp' @a = global i64 5 define i64 @__tempfunc() { entry: %a_val = load i64* @a ret i64 %a_val } This output is generated by LLVMDumpModule just before I call LLVMRunFunction. Which yields a LLVMGenericValueRef. However converting the result to a 64bit integer via
2008 May 24
0
[LLVMdev] A quick update on FreeBSD support
On May 24, 2008, at 11:43 AM, Marcel Moolenaar wrote: > All, > > So far I've tried LLVM on amd64, i386, ia64 and powerpc under FreeBSD > and aside for ia64, things look pretty good for a first try. There > are 2 unexpected failures for PowerPC, which appear to be caused by > uninitialized memory. I'm still working on a fix for that (need to > brush up on my C++
2008 May 24
2
[LLVMdev] A quick update on FreeBSD support
All, So far I've tried LLVM on amd64, i386, ia64 and powerpc under FreeBSD and aside for ia64, things look pretty good for a first try. There are 2 unexpected failures for PowerPC, which appear to be caused by uninitialized memory. I'm still working on a fix for that (need to brush up on my C++ skills). [sidenote: In FreeBSD -current, the memory allocator initializes memory with 0xa5