Displaying 7 results from an estimated 7 matches for "findcustomsafepoint".
Did you mean:
findcustomsafepoints
2011 Nov 01
2
[LLVMdev] Adding a custom GC safe point creation phase
...the
> GCStrategy can customize intrinsics lowering, or roots initialization. It
> works pretty well, as I've tested it on VMKit. So the patch in itself
> should not be controversial.
>
> Seems a perfectly reasonable patch on its own merits.
>
> I would be curious what your findCustomSafePoints implementation looks
> like. Perhaps it's possible to extract some of it into the framework.
>
The code for my findCustomSafePoints is like this:
void MyGC::findCustomSafePoints(GCFunctionInfo& FI, MachineFunction &MF) {
for (MachineFunction::iterator BBI = MF.begin(),...
2011 Oct 31
2
[LLVMdev] Adding a custom GC safe point creation phase
...n
// performCustomLowering must delete them.
bool customRoots() const { return CustomRoots; }
+
+ /// customSafePoints - By default, the GC analysis will find safe
+ /// points according to NeededSafePoints. If true,
+ /// then findCustomSafePoints must create them.
+ bool customSafePoints() const { return CustomSafePoints; }
/// initializeRoots - If set, gcroot intrinsics should initialize their
// allocas to null before the first use. This is
@@ -135,6 +145,7 @@
/// which the LLVM IR can be modified....
2011 Nov 01
0
[LLVMdev] Adding a custom GC safe point creation phase
...ar to the way the GCStrategy can customize intrinsics lowering, or roots initialization. It works pretty well, as I've tested it on VMKit. So the patch in itself should not be controversial.
>
> Seems a perfectly reasonable patch on its own merits.
>
> I would be curious what your findCustomSafePoints implementation looks like. Perhaps it's possible to extract some of it into the framework.
>
> The code for my findCustomSafePoints is like this:
>
> void MyGC::findCustomSafePoints(GCFunctionInfo& FI, MachineFunction &MF) {
> for (MachineFunction::iterator BBI = MF....
2011 Nov 01
0
[LLVMdev] Adding a custom GC safe point creation phase
...fepoints flag, similar to the way the GCStrategy can customize intrinsics lowering, or roots initialization. It works pretty well, as I've tested it on VMKit. So the patch in itself should not be controversial.
Seems a perfectly reasonable patch on its own merits.
I would be curious what your findCustomSafePoints implementation looks like. Perhaps it's possible to extract some of it into the framework.
> Chris, I'd like to discuss with you on how we can improve the current GC framework to take advantage of metadata. The reason I add this custom safe point creation method is because it's dif...
2014 Feb 24
2
[LLVMdev] Pointer vs Integer classification (was Re: make DataLayout a mandatory part of Module)
...r example), but could be hacked
around.
The problem comes up with backedge, function entry, and function return
safepoints. Given there is no example in tree (or out of tree that I
know of) which uses these, it's a little hard to tell how it's supposed
to work. My belief is that the findCustomSafePoints callback on
GCStrategy is supposed to insert these. The problem is that this pass
is a MachineFunction pass and this runs long after optimization.
The alternate approach - which I believe you're assuming - is to insert
calls for each safepoint explicitly before optimization. (In the blog...
2011 Nov 23
0
[LLVMdev] GC plugin: Not add (postcall) safe point after tail-call
Hi all,
I have implemented a GC plugin and i want to exclude Tail-call instructions
from being considered as Safe Points. For that reason I have overwritten
the "findCustomSafePoints" function with something like that:
bool ErlangGC::findCustomSafePoints(GCFunctionInfo &FI, MachineFunction
&MF) {
for (MachineFunction::iterator BBI = MF.begin(),
BBE = MF.end(); BBI != BBE;
++BBI)
for (MachineBasicBlock::iterat...
2014 Feb 24
2
[LLVMdev] Pointer vs Integer classification (was Re: make DataLayout a mandatory part of Module)
On 02/24/2014 12:45 AM, Andrew Trick wrote:
>
> On Feb 21, 2014, at 10:37 AM, Philip Reames <listmail at philipreames.com
> <mailto:listmail at philipreames.com>> wrote:
>
>>
>> On 02/14/2014 05:55 PM, Philip Reames wrote:
>>> Splitting out a conversation which started in "make DataLayout a
>>> mandatory part of Module" since the