search for: lowerintrinsics

...Yes, what you describe should be possible. In your GCStrategy subclass constructor, make the following change: class MyGCStrategy : public GCStrategy { MyGCStrategy() { - InitRoots = true; + CustomRoots = true; } + + bool performCustomLowering(Function &F) { + // You can use LowerIntrinsics::InsertRootInitializers as a template. + } }; LowerIntrinsics::InsertRootInitializers is only 26 lines of code. You can find it here: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/GCStrategy.cpp?annotate=123170#l174 More invasively, you could consider adding a hook to GCStrate...

Hello all, I set: InitRoots = true; in my gc plugin as i want the roots to be initialized to the "null" value. Is there a way to define which value should be the initial one? For example, i would like to initialize my roots to -5 (tagged, null value for the GC in my runtime system) instead of 0. Ofcourse, i could do it in the frontend (storing -5 to all GC roots), but i was wondering

Hi, I noticed that in line 288-289 of lib/CodeGen/GCStrategy.cpp there is a loop: > for (Function::iterator BB = F.begin(), E = F.end(); BB != E; ++BB) { > for (BasicBlock::iterator II = BB->begin(), E = BB->end(); > II != E;) { E is used both for F.end() and for BB->end(). Is this intended? -Y. -- Yiannis Tsiouris Ph.D.

|I noticed that in line 288-289 of lib/CodeGen/GCStrategy.cpp there is a |loop: |> for (Function::iterator BB = F.begin(), E = F.end(); BB != E; ++BB) { |> for (BasicBlock::iterator II = BB->begin(), E = BB->end(); |> II != E;) { |E is used both for F.end() and for BB->end(). Is this intended? Note that it's also being

...ce8 (C:\WINDOWS\System32\ucrtbase.dll+0xa6ce8) #5 0x7580618b (C:\WINDOWS\System32\ucrtbase.dll+0xa618b) #6 0x75806e26 (C:\WINDOWS\System32\ucrtbase.dll+0xa6e26) #7 0x013786a6 InsertRootInitializers c:\users\nikod\src\llvm\lib\codegen\gcrootlowering.cpp:172:0 #8 0x01378d97 `anonymous namespace'::LowerIntrinsics::PerformDefaultLowering c:\users\nikod\src\llvm\lib\codegen\gcrootlowering.cpp:249:0 #9 0x01379986 `anonymous namespace'::LowerIntrinsics::runOnFunction c:\users\nikod\src\llvm\lib\codegen\gcrootlowering.cpp:195:0 #10 0x016a343c llvm::FPPassManager::runOnFunction(class llvm::Function &) c:\...

...crtbase.dll+0xa6ce8) > #5 0x7580618b (C:\WINDOWS\System32\ucrtbase.dll+0xa618b) > #6 0x75806e26 (C:\WINDOWS\System32\ucrtbase.dll+0xa6e26) > #7 0x013786a6 InsertRootInitializers c:\users\nikod\src\llvm\lib\ > codegen\gcrootlowering.cpp:172:0 > #8 0x01378d97 `anonymous namespace'::LowerIntrinsics::PerformDefaultLowering > c:\users\nikod\src\llvm\lib\codegen\gcrootlowering.cpp:249:0 > #9 0x01379986 `anonymous namespace'::LowerIntrinsics::runOnFunction > c:\users\nikod\src\llvm\lib\codegen\gcrootlowering.cpp:195:0 > #10 0x016a343c llvm::FPPassManager::runOnFunction(class llvm:...

Hi I'm getting an assert in LowerIntrinsics::InsertRootInitializers because I'm gcroot'ing an alloca to a non-pointer. I was hoping to modify InsertRootInitializers to memset the structure in the case that it's not a pointer, but I'm not sure how to. Can anyone suggest what should go at "todo; something here"? ....

...seems appropriately factored. The alternative would seem to be calling a virtualized predicate on each machine instruction, as I don't think your debug info approach is something we would want to ‘bless’ just yet. You may need to align your safe point machine code analysis with [GCStrategy.cpp]LowerIntrinsics::CouldBecomeSafePoint. Note that this predicate operates on IR instructions instead of machine code. ― Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111101/6676b4fb/attachment.html>

Thanks for the review Gordon. On Tue, Nov 1, 2011 at 2:21 AM, Gordon Henriksen <gordonhenriksen at mac.com>wrote: > On 2011-10-31, at 17:21, Nicolas Geoffray wrote: > > > Here's a patch to allow a GCStrategy to customize the places where it > wants to insert safe points. I'm not sure who maintains the GC code today > in LLVM (I'd be happy to take ownership, if

On Nov 7, 2008, at 15:29, Scott Graham wrote: > I'm getting an assert in LowerIntrinsics::InsertRootInitializers > because I'm gcroot'ing an alloca to a non-pointer. > > I was hoping to modify InsertRootInitializers to memset the > structure in the case that it's not a pointer, but I'm not sure how > to. Can anyone suggest what should go at "to...

On Wed, 31 May 2006, Silken Tiger wrote: >> that requires a BasicBlockPass, it will fail the same was as when a >> ModulePass requires a FunctionPass. > void MParSchedule::getAnalysisUsage(AnalysisUsage &AU) const { > AU.setPreservesAll(); > } > > MParSchedule requires nothing and changes nothing. So hopefully the above code > represents this fact? Right

...asier for other front ends (like ours) which don't have the semantics > of libmath to generate code... The X86 visitCall should just handle any functions like sin/cos that can be directly codegen'd into machine code. For intrinsics you add, like llvm.sqrt, we should have code in the LowerIntrinsics code to lower it to a call to sqrt (for code generators that do not support it), but the X86 backend and many others could support it natively. Finally, for fabs, we should just be able to recognize the setcc/select pair and generate that instruction. -Chris -- http://nondot.org/sabre/ http:...

...(AnalysisUsage &AU) const { AU.addRequired<LoopInfo>(); AU.addRequired<MParSchedule>(); AU.setPreservesAll(); } and then in the runOnFunction pass of this backend: LI = &getAnalysis<LoopInfo>(); MParSchedule &MPar = getAnalysis<MParSchedule>(); lowerIntrinsics(F); printFloatingPointConstants(F); F.renameLocalSymbols(); list<Schedule *>* ScheduleList; Schedule *currentSchedule; for (Function::iterator i = F.begin(), e = F.end(); i != e; ++i) { for(BasicBlock::iterator j=i->begin(),bbe=i->end();j!=bbe;++j) { BasicBlock *bb; if((bb=d...

Hello, I'm currently adding the floating point math instructions (fabs, fsin, fcos ...) to the x86 instruction set. I'm a bit unsure how to make the back end actually generate these instructions, though. My current plan is to add llvm intrinsics for these instructions but I've noticed that llvm already handles C math library functions to some extent. It feels a bit strange to add

Hi Am Dienstag, 30. Mai 2006 19:21 schrieb Chris Lattner: > On Tue, 30 May 2006, Silken Tiger wrote: > > Everthing now compiles fine, but when running llc with invoking my own > > backend derived from the cbackend i get the following error: > > namespace llvm { > > class MParSchedule : public BasicBlockPass { > > public: > > > >

On Mon, May 10, 2010 at 7:19 PM, John Criswell <criswell at uiuc.edu> wrote: > SHEN Hao wrote: >> Thanks a lot for your answer. >> As what you said, I can not have any options to avoid generating this kind >> of intrinsic for byte code. Is it possible to modify gcc and ask it take >> all memset liked functions as a general function call? I know this solution