Displaying 5 results from an estimated 5 matches for "potman".
Did you mean:
podman
2012 Jun 12
2
[LLVMdev] Latency of true depency of store followed by aliased load in ScheduleDAGInstrs
...duleDAGInstrs in a scheduler for a VLIW target and in the
volatile case the load gets incorrectly scheduled in the same cycle as
the store. Is ScheduleDAGInstrs incorrect in the volatile case or
shouldn't I rely on the latency being non zero for getting a correct
schedule?
Best regards,
Jordy Potman
-------------- next part --------------
; ModuleID = 'store_load_latency_test.c'
target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:32:64-v128:32:128-a0:0:32-n32-S32"
target triple = "armv4t--"
define i32 @f1(i32* nocap...
2013 Jan 11
1
[LLVMdev] Arguments to setLatencyPolicy calls swapped by accident in ConvergingScheduler::checkResourceLimits?
Hi,
In ConvergingScheduler::checkResourceLimits on line 1535 of
MachineScheduler.cpp setLatencyPolicy is called as follows:
// Set ReduceLatency to true if needed.
Bot.setLatencyPolicy(TopCand.Policy);
Top.setLatencyPolicy(BotCand.Policy);
So the Bot scheduling boundary is used to set the latency policy of the
Top candidate and the other way around.
I think this should be:
//
2012 Jun 13
0
[LLVMdev] Latency of true depency of store followed by aliased load in ScheduleDAGInstrs
On Jun 12, 2012, at 7:20 AM, Jordy Potman <jordy.potman at recoresystems.com> wrote:
>
> So in the volatile case the latency of the chain dependency is 0, while
> in the non volatile case it is 1.
>
> I am using ScheduleDAGInstrs in a scheduler for a VLIW target and in the
> volatile case the load gets incorrectly...
2012 Aug 13
1
[LLVMdev] [RFC] Bundling support in the PostRA Scheduler
Hi all,
Thanks for your feed-backs :-)
@Andrew: In fact, I've reused most of the postRA list scheduler code and
the resource priority queue. Every time it needs to move forward, either
because of a res hazard (HazardRec) or an invalid combination of
instructions in the current packet (DFA), it closes the current bundle
and advances to the next cycle. The non-interlocked nature of our
2011 Nov 02
0
[LLVMdev] Issues in compiler-rt __truncdfsf2 and __extendsfdf2 functions?
Hi all,
We are using compiler-rt for floating point emulation on our DSP core. I
am currently investigating two issues found by running TestFloat [1] on
our core.
The first issue is in __truncdfsf2. __truncdfsf2(0x1p+128) produces
0x1p-128, while the expected result is inf. __truncdfsf2(-0x1p+128)
produces -0x1p-128, while the expected result is -inf. I think the
condition of the else if on line