LuaJIT - Trace aborted again

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

LuaJIT - Trace aborted again

Benjamin Segovia
Hello all,
still in the context of asm-from-one-machine to lua translation, I am
facing some difficulties.
For various reasons (mostly because the machine I am simulating is a
SIMD vector machine), I need to handle forward jumps with the idiom:

while true do
{... a lot of compute ...}
if some_condition_on_the_lane_of_the_simd_vector then break end
{... a lot of compute ...}
break -- this one is to exit anyway
end

So, basic blocks are handled with these idioms.

This creates a large number of nested branches but statiscally in my
example, they are always taken in the same way.

Unfortunately, as the nesting grows, luaJIT finally "breaks" ie it is
not able to generate x86 code even if the quantity of serial
computations (no branch) is huge.

Mostly, I think the error is "loop unroll limit reached"

Strangely, there is no loops to unroll in my code.

Is there anyway to change luaJIT heuristics to force compilation?

Each basic block has a pretty large amount of compute but still,
luaJIT is still very sensitive to the number of "while true do {  ...
} end" statements I added.

I can email the trace but it is pretty big

Ben

Reply | Threaded
Open this post in threaded view
|

Re: LuaJIT - Trace aborted again

Benjamin Segovia
I am not sure to understand but basically, I am however able to
generate many small traces by removing some "unrolling" I had before.
As I said, I have a SIMD machine to simulate and therefore, initially,
I just unrolled the per-lane computations.
When you do:
vec0 = vec1 + vec2
I basically output something like:
vec0[0] = vec1[0] + vec2[0]
vec0[1] = vec1[1] + vec2[1]
....

If I do:
for i=1,simd_width do vec0[i] = vec1[i] + vec2[i] end
then a trace is generated for this small loop

Basically, I am not able to generate few large traces with LuaJIT but
I am able to generate many small ones.

Cheers,
Ben



On Wed, Jul 20, 2011 at 6:49 AM, Benjamin Segovia
<[hidden email]> wrote:

> Hello all,
> still in the context of asm-from-one-machine to lua translation, I am
> facing some difficulties.
> For various reasons (mostly because the machine I am simulating is a
> SIMD vector machine), I need to handle forward jumps with the idiom:
>
> while true do
> {... a lot of compute ...}
> if some_condition_on_the_lane_of_the_simd_vector then break end
> {... a lot of compute ...}
> break -- this one is to exit anyway
> end
>
> So, basic blocks are handled with these idioms.
>
> This creates a large number of nested branches but statiscally in my
> example, they are always taken in the same way.
>
> Unfortunately, as the nesting grows, luaJIT finally "breaks" ie it is
> not able to generate x86 code even if the quantity of serial
> computations (no branch) is huge.
>
> Mostly, I think the error is "loop unroll limit reached"
>
> Strangely, there is no loops to unroll in my code.
>
> Is there anyway to change luaJIT heuristics to force compilation?
>
> Each basic block has a pretty large amount of compute but still,
> luaJIT is still very sensitive to the number of "while true do {  ...
> } end" statements I added.
>
> I can email the trace but it is pretty big
>
> Ben
>

Reply | Threaded
Open this post in threaded view
|

Re: LuaJIT - Trace aborted again

David Kastrup
In reply to this post by Benjamin Segovia
Benjamin Segovia <[hidden email]> writes:

> Hello all,
> still in the context of asm-from-one-machine to lua translation, I am
> facing some difficulties.
> For various reasons (mostly because the machine I am simulating is a
> SIMD vector machine), I need to handle forward jumps with the idiom:
>
> while true do
> {... a lot of compute ...}
> if some_condition_on_the_lane_of_the_simd_vector then break end
> {... a lot of compute ...}
> break -- this one is to exit anyway
> end
>
> So, basic blocks are handled with these idioms.

That's not a nice idiom.  Perhaps

repeat
...
until false

is better recognizable to luajit?  That way the fall-through exit is
more conspicuous.  And since it is more idiomatic, chances are better
that Mike caters for this...

--
David Kastrup


Reply | Threaded
Open this post in threaded view
|

Re: LuaJIT - Trace aborted again

Benjamin Segovia
Actually, I naturally tried this one before the while true do {...} end
Same result unfortunately :-)
Ben


On Wed, Jul 20, 2011 at 7:21 AM, David Kastrup <[hidden email]> wrote:

> Benjamin Segovia <[hidden email]> writes:
>
>> Hello all,
>> still in the context of asm-from-one-machine to lua translation, I am
>> facing some difficulties.
>> For various reasons (mostly because the machine I am simulating is a
>> SIMD vector machine), I need to handle forward jumps with the idiom:
>>
>> while true do
>> {... a lot of compute ...}
>> if some_condition_on_the_lane_of_the_simd_vector then break end
>> {... a lot of compute ...}
>> break -- this one is to exit anyway
>> end
>>
>> So, basic blocks are handled with these idioms.
>
> That's not a nice idiom.  Perhaps
>
> repeat
> ...
> until false
>
> is better recognizable to luajit?  That way the fall-through exit is
> more conspicuous.  And since it is more idiomatic, chances are better
> that Mike caters for this...
>
> --
> David Kastrup
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: LuaJIT - Trace aborted again

Benjamin Segovia
BTW, this is "until true" :-)
I just rechecked with a simple example (which generates a compiled
trace), the code is the same actually.
Ben


On Wed, Jul 20, 2011 at 7:26 AM, Benjamin Segovia
<[hidden email]> wrote:

> Actually, I naturally tried this one before the while true do {...} end
> Same result unfortunately :-)
> Ben
>
>
> On Wed, Jul 20, 2011 at 7:21 AM, David Kastrup <[hidden email]> wrote:
>> Benjamin Segovia <[hidden email]> writes:
>>
>>> Hello all,
>>> still in the context of asm-from-one-machine to lua translation, I am
>>> facing some difficulties.
>>> For various reasons (mostly because the machine I am simulating is a
>>> SIMD vector machine), I need to handle forward jumps with the idiom:
>>>
>>> while true do
>>> {... a lot of compute ...}
>>> if some_condition_on_the_lane_of_the_simd_vector then break end
>>> {... a lot of compute ...}
>>> break -- this one is to exit anyway
>>> end
>>>
>>> So, basic blocks are handled with these idioms.
>>
>> That's not a nice idiom.  Perhaps
>>
>> repeat
>> ...
>> until false
>>
>> is better recognizable to luajit?  That way the fall-through exit is
>> more conspicuous.  And since it is more idiomatic, chances are better
>> that Mike caters for this...
>>
>> --
>> David Kastrup
>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: LuaJIT - Trace aborted again

David Kastrup
Benjamin Segovia <[hidden email]> writes:

> BTW, this is "until true" :-)

Argl.  So much for being idiomatic.  Probably the C condition (which is
reversed) stuck in my head.

--
David Kastrup


Reply | Threaded
Open this post in threaded view
|

Re: LuaJIT - Trace aborted again

Benjamin Segovia
Actually, I did exactly the same thing initially. Too much do { }
while (0) macros :-)
Ben


On Wed, Jul 20, 2011 at 7:41 AM, David Kastrup <[hidden email]> wrote:

> Benjamin Segovia <[hidden email]> writes:
>
>> BTW, this is "until true" :-)
>
> Argl.  So much for being idiomatic.  Probably the C condition (which is
> reversed) stuck in my head.
>
> --
> David Kastrup
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: LuaJIT - Trace aborted again

Tony Finch
In reply to this post by Benjamin Segovia
Benjamin Segovia <[hidden email]> wrote:

> I need to handle forward jumps with the idiom:
>
> while true do
> {... a lot of compute ...}
> if some_condition_on_the_lane_of_the_simd_vector then break end
> {... a lot of compute ...}
> break -- this one is to exit anyway
> end

Why not this?

  {... a lot of compute ...}
  if not some_condition_on_the_lane_of_the_simd_vector then
    {... a lot of compute ...}
  end

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
Tyne, Dogger: Variable becoming northeast, 3 or 4. Slight or moderate.
Thundery showers. Good, occasionally poor.

Reply | Threaded
Open this post in threaded view
|

Re: LuaJIT - Trace aborted again

Benjamin Segovia
It is more complicated to generate the code like that because there
may be a lot of "break instruction" (the machine supports native
structured branch instructions) and this will require to _nest_ more
and more successive basic blocks into if statements.
In C, you will just use goto. Here I really try to simulate a forward branch.

Also, LuaJIT really behaves strangely. Because using lot of branches
to simulate forward jumps does not seem to be really the problem. The
weird thing is that for some reason, if a sequence of _lua_ statements
with no branch at all is too _big_ then no trace is compiled. If I add
for loops for each statement (I do _not_ unroll the vector
computations), then the for loops are compiled and performance is way
better.

Also, when I do:
vec2[i] = vec1[i] + vec0[i]

vec2.vec1 and vec0 also are ffi arrays (allocated with ffi.new(...))
and sse conversions instruction must be issued back and forth (for
reads and writes) since vec* are used to simulate register files with
different element size (byte,word,dword...)


Ben


On Wed, Jul 20, 2011 at 9:47 AM, Tony Finch <[hidden email]> wrote:

> Benjamin Segovia <[hidden email]> wrote:
>
>> I need to handle forward jumps with the idiom:
>>
>> while true do
>> {... a lot of compute ...}
>> if some_condition_on_the_lane_of_the_simd_vector then break end
>> {... a lot of compute ...}
>> break -- this one is to exit anyway
>> end
>
> Why not this?
>
>  {... a lot of compute ...}
>  if not some_condition_on_the_lane_of_the_simd_vector then
>    {... a lot of compute ...}
>  end
>
> Tony.
> --
> f.anthony.n.finch  <[hidden email]>  http://dotat.at/
> Tyne, Dogger: Variable becoming northeast, 3 or 4. Slight or moderate.
> Thundery showers. Good, occasionally poor.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: LuaJIT - Trace aborted again

Benjamin Segovia
... and conversion is of course the behaviour we want since in Lua,
every computation is done with double. But still, maybe that may make
sense to notify this point

On Wed, Jul 20, 2011 at 10:03 AM, Benjamin Segovia
<[hidden email]> wrote:

> It is more complicated to generate the code like that because there
> may be a lot of "break instruction" (the machine supports native
> structured branch instructions) and this will require to _nest_ more
> and more successive basic blocks into if statements.
> In C, you will just use goto. Here I really try to simulate a forward branch.
>
> Also, LuaJIT really behaves strangely. Because using lot of branches
> to simulate forward jumps does not seem to be really the problem. The
> weird thing is that for some reason, if a sequence of _lua_ statements
> with no branch at all is too _big_ then no trace is compiled. If I add
> for loops for each statement (I do _not_ unroll the vector
> computations), then the for loops are compiled and performance is way
> better.
>
> Also, when I do:
> vec2[i] = vec1[i] + vec0[i]
>
> vec2.vec1 and vec0 also are ffi arrays (allocated with ffi.new(...))
> and sse conversions instruction must be issued back and forth (for
> reads and writes) since vec* are used to simulate register files with
> different element size (byte,word,dword...)
>
>
> Ben
>
>
> On Wed, Jul 20, 2011 at 9:47 AM, Tony Finch <[hidden email]> wrote:
>> Benjamin Segovia <[hidden email]> wrote:
>>
>>> I need to handle forward jumps with the idiom:
>>>
>>> while true do
>>> {... a lot of compute ...}
>>> if some_condition_on_the_lane_of_the_simd_vector then break end
>>> {... a lot of compute ...}
>>> break -- this one is to exit anyway
>>> end
>>
>> Why not this?
>>
>>  {... a lot of compute ...}
>>  if not some_condition_on_the_lane_of_the_simd_vector then
>>    {... a lot of compute ...}
>>  end
>>
>> Tony.
>> --
>> f.anthony.n.finch  <[hidden email]>  http://dotat.at/
>> Tyne, Dogger: Variable becoming northeast, 3 or 4. Slight or moderate.
>> Thundery showers. Good, occasionally poor.
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: LuaJIT - Trace aborted again

Benjamin Segovia
Basically, I think the issue is somehow:
if you have a very long instruction stream with no branch inside a
deeply nested branch, there is a problem to generate traces.
Something like that.
I will try to make a self contained code tomorrow.

Ben


On Wed, Jul 20, 2011 at 10:05 AM, Benjamin Segovia
<[hidden email]> wrote:

> ... and conversion is of course the behaviour we want since in Lua,
> every computation is done with double. But still, maybe that may make
> sense to notify this point
>
> On Wed, Jul 20, 2011 at 10:03 AM, Benjamin Segovia
> <[hidden email]> wrote:
>> It is more complicated to generate the code like that because there
>> may be a lot of "break instruction" (the machine supports native
>> structured branch instructions) and this will require to _nest_ more
>> and more successive basic blocks into if statements.
>> In C, you will just use goto. Here I really try to simulate a forward branch.
>>
>> Also, LuaJIT really behaves strangely. Because using lot of branches
>> to simulate forward jumps does not seem to be really the problem. The
>> weird thing is that for some reason, if a sequence of _lua_ statements
>> with no branch at all is too _big_ then no trace is compiled. If I add
>> for loops for each statement (I do _not_ unroll the vector
>> computations), then the for loops are compiled and performance is way
>> better.
>>
>> Also, when I do:
>> vec2[i] = vec1[i] + vec0[i]
>>
>> vec2.vec1 and vec0 also are ffi arrays (allocated with ffi.new(...))
>> and sse conversions instruction must be issued back and forth (for
>> reads and writes) since vec* are used to simulate register files with
>> different element size (byte,word,dword...)
>>
>>
>> Ben
>>
>>
>> On Wed, Jul 20, 2011 at 9:47 AM, Tony Finch <[hidden email]> wrote:
>>> Benjamin Segovia <[hidden email]> wrote:
>>>
>>>> I need to handle forward jumps with the idiom:
>>>>
>>>> while true do
>>>> {... a lot of compute ...}
>>>> if some_condition_on_the_lane_of_the_simd_vector then break end
>>>> {... a lot of compute ...}
>>>> break -- this one is to exit anyway
>>>> end
>>>
>>> Why not this?
>>>
>>>  {... a lot of compute ...}
>>>  if not some_condition_on_the_lane_of_the_simd_vector then
>>>    {... a lot of compute ...}
>>>  end
>>>
>>> Tony.
>>> --
>>> f.anthony.n.finch  <[hidden email]>  http://dotat.at/
>>> Tyne, Dogger: Variable becoming northeast, 3 or 4. Slight or moderate.
>>> Thundery showers. Good, occasionally poor.
>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: LuaJIT - Trace aborted again

Dirk Laurie
In reply to this post by Benjamin Segovia
On Wed, Jul 20, 2011 at 12:03:43PM +0200, Benjamin Segovia wrote:
> In C, you will just use goto.

Also in Lua 5.2.0-beta.

Dirk

Reply | Threaded
Open this post in threaded view
|

Re: LuaJIT - Trace aborted again

Mike Pall-29
In reply to this post by Benjamin Segovia
Benjamin Segovia wrote:
> For various reasons (mostly because the machine I am simulating is a
> SIMD vector machine), I need to handle forward jumps with the idiom:
>
> while true do
> {... a lot of compute ...}
> if some_condition_on_the_lane_of_the_simd_vector then break end
> {... a lot of compute ...}
> break -- this one is to exit anyway
> end

Well, you're (ab)using a loop construct where you really want a
simple branch. The region selection heuristics of LuaJIT don't
appreciate it, if you abuse control-flow constructs like that.

> Mostly, I think the error is "loop unroll limit reached"
>
> Strangely, there is no loops to unroll in my code.

Of course there's a loop, because you used a loop construct.
Whether that loop actually loops back is an orthogonal issue.

In fact, as you can see from the message, it recognizes this and
unrolls the loop. But there has to be a total limit per trace for
the number of unrolls. See: http://luajit.org/running.html#opt_O

So you should use an if/then/else construct, because that's what
it really is.

> It is more complicated to generate the code like that because there
> may be a lot of "break instruction" (the machine supports native
> structured branch instructions) and this will require to _nest_ more
> and more successive basic blocks into if statements.

I do not see how that's different from doing it with a while loop.
You'd need to nest them and close them with 'end' as well.

> In C, you will just use goto. Here I really try to simulate a forward branch.

I might add goto to LuaJIT sometime (busy right now).

> Also, LuaJIT really behaves strangely. Because using lot of branches
> to simulate forward jumps does not seem to be really the problem. The
> weird thing is that for some reason, if a sequence of _lua_ statements
> with no branch at all is too _big_ then no trace is compiled.

It needs to be _really_ big. The unroll limit hits first for your
example.

> If I add for loops for each statement (I do _not_ unroll the
> vector computations), then the for loops are compiled and
> performance is way better.

Then the inner loops are compiled first and stitched together with
side traces. That's less efficient, especially when the inner
loops have a low iteration count. It's still faster than if it
fails to compile anything at all. But you're missing out on the
max. performance.

It works like this:

  Step 1       Step 2       Step 3       Step 4
                                         .---------.
                                         V         |
  Loop1<--.    Loop1<--.    Loop1<--.    Loop1<--. |
    `-----'      `-----'    | `-----'    | `-----' |
                            |            |         |
               Loop2<--.    Loop2<--.    Loop1<--. |
                 `-----'      `-----'    | `-----' |
                                         |         |
                                         `---------'

But you really want this:

  .--------.
  V        |
  Loop1[0] |
  Loop1[1] |
  Loop1[2] |
  |        |
  Loop2[0] |
  Loop2[1] |
  Loop2[2] |
  |        |
  `--------'

--Mike

Reply | Threaded
Open this post in threaded view
|

Re: LuaJIT - Trace aborted again

David Kastrup
Mike Pall <[hidden email]> writes:

> Benjamin Segovia wrote:
>
>> It is more complicated to generate the code like that because there
>> may be a lot of "break instruction" (the machine supports native
>> structured branch instructions) and this will require to _nest_ more
>> and more successive basic blocks into if statements.
>
> I do not see how that's different from doing it with a while loop.
> You'd need to nest them and close them with 'end' as well.

No, you need just a single loop at a time that can deal with dozens of
"break" in there.

--
David Kastrup


Reply | Threaded
Open this post in threaded view
|

Re: LuaJIT - Trace aborted again

Robert Raschke


On Wed, Jul 20, 2011 at 3:43 PM, David Kastrup <[hidden email]> wrote:
Mike Pall <[hidden email]> writes:

> Benjamin Segovia wrote:
>
>> It is more complicated to generate the code like that because there
>> may be a lot of "break instruction" (the machine supports native
>> structured branch instructions) and this will require to _nest_ more
>> and more successive basic blocks into if statements.
>
> I do not see how that's different from doing it with a while loop.
> You'd need to nest them and close them with 'end' as well.

No, you need just a single loop at a time that can deal with dozens of
"break" in there.


So instead of:

while true do
   {... a lot of compute ...}
   if some_condition_on_the_lane_of_the_simd_vector then break end
   {... a lot of compute ...}
   break -- this one is to exit anyway
end

you could generate

(function ()
   {... a lot of compute ...}
   if some_condition_on_the_lane_of_the_simd_vector then return end
   {... a lot of compute ...}
   return
end)()

But I'm probably missing something.

Robby

Reply | Threaded
Open this post in threaded view
|

Re: LuaJIT - Trace aborted again

Mike Pall-29
In reply to this post by David Kastrup
David Kastrup wrote:
> Mike Pall <[hidden email]> writes:
> > I do not see how that's different from doing it with a while loop.
> > You'd need to nest them and close them with 'end' as well.
>
> No, you need just a single loop at a time that can deal with dozens of
> "break" in there.

Sure. But is that a realistic use case? If the VLIW code is
generated from typical code in a high-level language, I doubt
you'd see more than a handful of these. Nesting (say) 100
if/then/else is no problem.

--Mike

Reply | Threaded
Open this post in threaded view
|

Re: LuaJIT - Trace aborted again

Benjamin Segovia
Hmmm.
This is not really a if/then/else construct I need but really a
forward jump. Basically, it is a SIMD scatter/gather machine. Some
instructions inactivate lanes from the SIMD vector. In a block, if
your instruction currently deactivates all lanes, then you exit the
block, reset the mask you got before potentially modified by the
computations in the previous block. Then you check the current mask.
If it is still zero, then you exit the block ...

Maybe to be more precise: the biggest issue basically is that I need
to emulate "continue" and "breaks" because the machine can execute
"continue" and "break" instructions natively.
Actually "continue" instructions are really the big problem, since
there is no continue in lua.

Right now, I used a two-nested-loop hack to handle continue:

repeat
local a_break_was_used_for_a_continue = false
repeat

-- .... "CONTINUE"  instruction generates ->
a_break_was_used_for_a_continue = true
break
-- end of continue

-- .... "BREAK" instruction generates ->
a_break_was_used_for_a_continue = false
break
-- end of break

until true -- <- this is fake loop to early branch out (used for
breaks and continues)
if not a_break_was_used_for_a_continue then beak end
until false -- <- this is a real loop. Youhou!

As you can see, the technique is easy to implement since regardless
where I am in the nested branches (like for example, deeply nested in
IFs), I can early out.
I am afraid that using only if/then/else to mask the code may be a
more serious code transform. Something similar to unstructured
branches to structures branches transform... ie not that easy to do
:-)

I will try other things today.

Thank you very much for your help

Ben



On Wed, Jul 20, 2011 at 2:52 PM, Mike Pall <[hidden email]> wrote:

> David Kastrup wrote:
>> Mike Pall <[hidden email]> writes:
>> > I do not see how that's different from doing it with a while loop.
>> > You'd need to nest them and close them with 'end' as well.
>>
>> No, you need just a single loop at a time that can deal with dozens of
>> "break" in there.
>
> Sure. But is that a realistic use case? If the VLIW code is
> generated from typical code in a high-level language, I doubt
> you'd see more than a handful of these. Nesting (say) 100
> if/then/else is no problem.
>
> --Mike
>
>

Reply | Threaded
Open this post in threaded view
|

Re: LuaJIT - Trace aborted again

Benjamin Segovia
Also, Robert, I will try your suggestion :-)
I hope it will work ie replacing my hack (nested double loop) by the
(function() ... end)() hack. Using a function for each loop body, I
can replace breaks / continues by returns and remove one repeat ...
until crap.
I hope it will do the job :-)
Otherwise, I will try to go through if/then/else code transform hell...
So, also thanks for the suggestion :-)

Ben


On Wed, Jul 20, 2011 at 4:45 PM, Benjamin Segovia
<[hidden email]> wrote:

> Hmmm.
> This is not really a if/then/else construct I need but really a
> forward jump. Basically, it is a SIMD scatter/gather machine. Some
> instructions inactivate lanes from the SIMD vector. In a block, if
> your instruction currently deactivates all lanes, then you exit the
> block, reset the mask you got before potentially modified by the
> computations in the previous block. Then you check the current mask.
> If it is still zero, then you exit the block ...
>
> Maybe to be more precise: the biggest issue basically is that I need
> to emulate "continue" and "breaks" because the machine can execute
> "continue" and "break" instructions natively.
> Actually "continue" instructions are really the big problem, since
> there is no continue in lua.
>
> Right now, I used a two-nested-loop hack to handle continue:
>
> repeat
> local a_break_was_used_for_a_continue = false
> repeat
>
> -- .... "CONTINUE"  instruction generates ->
> a_break_was_used_for_a_continue = true
> break
> -- end of continue
>
> -- .... "BREAK" instruction generates ->
> a_break_was_used_for_a_continue = false
> break
> -- end of break
>
> until true -- <- this is fake loop to early branch out (used for
> breaks and continues)
> if not a_break_was_used_for_a_continue then beak end
> until false -- <- this is a real loop. Youhou!
>
> As you can see, the technique is easy to implement since regardless
> where I am in the nested branches (like for example, deeply nested in
> IFs), I can early out.
> I am afraid that using only if/then/else to mask the code may be a
> more serious code transform. Something similar to unstructured
> branches to structures branches transform... ie not that easy to do
> :-)
>
> I will try other things today.
>
> Thank you very much for your help
>
> Ben
>
>
>
> On Wed, Jul 20, 2011 at 2:52 PM, Mike Pall <[hidden email]> wrote:
>> David Kastrup wrote:
>>> Mike Pall <[hidden email]> writes:
>>> > I do not see how that's different from doing it with a while loop.
>>> > You'd need to nest them and close them with 'end' as well.
>>>
>>> No, you need just a single loop at a time that can deal with dozens of
>>> "break" in there.
>>
>> Sure. But is that a realistic use case? If the VLIW code is
>> generated from typical code in a high-level language, I doubt
>> you'd see more than a handful of these. Nesting (say) 100
>> if/then/else is no problem.
>>
>> --Mike
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: LuaJIT - Trace aborted again

Benjamin Segovia
Unfortunately, no sucess. I encapsulated basic blocks into functions
and add return statement instead of breaks. Exactly the same result.
As I am not sure of what to do next, please find here a dump of the
function I tried to compile. I just extracted it and made a
stand-alone file with it. Mike, if you have an idea of what is going
on.

Cheers,
Ben

On Wed, Jul 20, 2011 at 4:49 PM, Benjamin Segovia
<[hidden email]> wrote:

> Also, Robert, I will try your suggestion :-)
> I hope it will work ie replacing my hack (nested double loop) by the
> (function() ... end)() hack. Using a function for each loop body, I
> can replace breaks / continues by returns and remove one repeat ...
> until crap.
> I hope it will do the job :-)
> Otherwise, I will try to go through if/then/else code transform hell...
> So, also thanks for the suggestion :-)
>
> Ben
>
>
> On Wed, Jul 20, 2011 at 4:45 PM, Benjamin Segovia
> <[hidden email]> wrote:
>> Hmmm.
>> This is not really a if/then/else construct I need but really a
>> forward jump. Basically, it is a SIMD scatter/gather machine. Some
>> instructions inactivate lanes from the SIMD vector. In a block, if
>> your instruction currently deactivates all lanes, then you exit the
>> block, reset the mask you got before potentially modified by the
>> computations in the previous block. Then you check the current mask.
>> If it is still zero, then you exit the block ...
>>
>> Maybe to be more precise: the biggest issue basically is that I need
>> to emulate "continue" and "breaks" because the machine can execute
>> "continue" and "break" instructions natively.
>> Actually "continue" instructions are really the big problem, since
>> there is no continue in lua.
>>
>> Right now, I used a two-nested-loop hack to handle continue:
>>
>> repeat
>> local a_break_was_used_for_a_continue = false
>> repeat
>>
>> -- .... "CONTINUE"  instruction generates ->
>> a_break_was_used_for_a_continue = true
>> break
>> -- end of continue
>>
>> -- .... "BREAK" instruction generates ->
>> a_break_was_used_for_a_continue = false
>> break
>> -- end of break
>>
>> until true -- <- this is fake loop to early branch out (used for
>> breaks and continues)
>> if not a_break_was_used_for_a_continue then beak end
>> until false -- <- this is a real loop. Youhou!
>>
>> As you can see, the technique is easy to implement since regardless
>> where I am in the nested branches (like for example, deeply nested in
>> IFs), I can early out.
>> I am afraid that using only if/then/else to mask the code may be a
>> more serious code transform. Something similar to unstructured
>> branches to structures branches transform... ie not that easy to do
>> :-)
>>
>> I will try other things today.
>>
>> Thank you very much for your help
>>
>> Ben
>>
>>
>>
>> On Wed, Jul 20, 2011 at 2:52 PM, Mike Pall <[hidden email]> wrote:
>>> David Kastrup wrote:
>>>> Mike Pall <[hidden email]> writes:
>>>> > I do not see how that's different from doing it with a while loop.
>>>> > You'd need to nest them and close them with 'end' as well.
>>>>
>>>> No, you need just a single loop at a time that can deal with dozens of
>>>> "break" in there.
>>>
>>> Sure. But is that a realistic use case? If the VLIW code is
>>> generated from typical code in a high-level language, I doubt
>>> you'd see more than a handful of these. Nesting (say) 100
>>> if/then/else is no problem.
>>>
>>> --Mike
>>>
>>>
>>
>

no_compiled_trace.tgz (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: LuaJIT - Trace aborted again

Benjamin Segovia
Also, as you may see using  -jdump, there is no more "unroll loop"
issue when I use the function trick.
Ben

On Wed, Jul 20, 2011 at 11:20 PM, Benjamin Segovia
<[hidden email]> wrote:

> Unfortunately, no sucess. I encapsulated basic blocks into functions
> and add return statement instead of breaks. Exactly the same result.
> As I am not sure of what to do next, please find here a dump of the
> function I tried to compile. I just extracted it and made a
> stand-alone file with it. Mike, if you have an idea of what is going
> on.
>
> Cheers,
> Ben
>
> On Wed, Jul 20, 2011 at 4:49 PM, Benjamin Segovia
> <[hidden email]> wrote:
>> Also, Robert, I will try your suggestion :-)
>> I hope it will work ie replacing my hack (nested double loop) by the
>> (function() ... end)() hack. Using a function for each loop body, I
>> can replace breaks / continues by returns and remove one repeat ...
>> until crap.
>> I hope it will do the job :-)
>> Otherwise, I will try to go through if/then/else code transform hell...
>> So, also thanks for the suggestion :-)
>>
>> Ben
>>
>>
>> On Wed, Jul 20, 2011 at 4:45 PM, Benjamin Segovia
>> <[hidden email]> wrote:
>>> Hmmm.
>>> This is not really a if/then/else construct I need but really a
>>> forward jump. Basically, it is a SIMD scatter/gather machine. Some
>>> instructions inactivate lanes from the SIMD vector. In a block, if
>>> your instruction currently deactivates all lanes, then you exit the
>>> block, reset the mask you got before potentially modified by the
>>> computations in the previous block. Then you check the current mask.
>>> If it is still zero, then you exit the block ...
>>>
>>> Maybe to be more precise: the biggest issue basically is that I need
>>> to emulate "continue" and "breaks" because the machine can execute
>>> "continue" and "break" instructions natively.
>>> Actually "continue" instructions are really the big problem, since
>>> there is no continue in lua.
>>>
>>> Right now, I used a two-nested-loop hack to handle continue:
>>>
>>> repeat
>>> local a_break_was_used_for_a_continue = false
>>> repeat
>>>
>>> -- .... "CONTINUE"  instruction generates ->
>>> a_break_was_used_for_a_continue = true
>>> break
>>> -- end of continue
>>>
>>> -- .... "BREAK" instruction generates ->
>>> a_break_was_used_for_a_continue = false
>>> break
>>> -- end of break
>>>
>>> until true -- <- this is fake loop to early branch out (used for
>>> breaks and continues)
>>> if not a_break_was_used_for_a_continue then beak end
>>> until false -- <- this is a real loop. Youhou!
>>>
>>> As you can see, the technique is easy to implement since regardless
>>> where I am in the nested branches (like for example, deeply nested in
>>> IFs), I can early out.
>>> I am afraid that using only if/then/else to mask the code may be a
>>> more serious code transform. Something similar to unstructured
>>> branches to structures branches transform... ie not that easy to do
>>> :-)
>>>
>>> I will try other things today.
>>>
>>> Thank you very much for your help
>>>
>>> Ben
>>>
>>>
>>>
>>> On Wed, Jul 20, 2011 at 2:52 PM, Mike Pall <[hidden email]> wrote:
>>>> David Kastrup wrote:
>>>>> Mike Pall <[hidden email]> writes:
>>>>> > I do not see how that's different from doing it with a while loop.
>>>>> > You'd need to nest them and close them with 'end' as well.
>>>>>
>>>>> No, you need just a single loop at a time that can deal with dozens of
>>>>> "break" in there.
>>>>
>>>> Sure. But is that a realistic use case? If the VLIW code is
>>>> generated from typical code in a high-level language, I doubt
>>>> you'd see more than a handful of these. Nesting (say) 100
>>>> if/then/else is no problem.
>>>>
>>>> --Mike
>>>>
>>>>
>>>
>>
>

12