I wonder if the fuel is also being used by "essential" transformations,
like the CPS pass?
Cheers,
Simon
On 03/02/2011 09:01, Simon Peyton-Jones wrote:
Correct. The Cmm optimiser is supposed to make correctness preserving transformations.
The idea of the "fuel" is that you can binary chop your way to a situation where
Fuel = 0-143 Program works
Fuel = 144 Program crashes
Then look at the single transformation that introduces the crash.
Well that's the intent anyway!
Simon
| -----Original Message-----
| From: ezyang [mailto:ezy...@mit.edu]
| Sent: 02 February 2011 23:12
| To: Simon Marlow; Simon Peyton-Jones
| Cc: glasgow-haskell-users
| Subject: Re: 4221 on new codegen
|
| Simon Peyton Jones, I have a question about optimization fuel and GHC panics.
| When I vary the fuel using -dopt-fuel, I get the following varying behavior:
|
| ...
| -dopt-fuel=144 = normal segfault (late in the program)
| -dopt-fuel=143 = segfaults ~immediately
| -dopt-fuel=142 = normal segfault
| -dopt-fuel=141 = fails an assert in file compiler/cmm/CmmBuildInfoTables.hs,
| line 128
| -dopt-fuel=140 = ditto
| -dopt-fuel=139 = resulting executable prints 'start' and then doesn't do
| anything
| ...
|
| My impression was that these optimizations should not affect program
| behavior,
| in which case the first thing I should figure out is why -dopt-fuel results
| in
| the programming terminating after it prints 'start'. However, I'm not sure if
| this is a red herring. Am I on the right track?
|
| Cheers,
| Edward
|
| Quoting Simon Marlow<marlo...@gmail.com>:
|
|> On 02/02/2011 00:29, Edward Z. Yang wrote:
|>> More Hoopling later, I see this segment in the rewrite function:
|>>
|>> middle m@(CmmUnsafeForeignCall _ fs _) live = return $
|>> case map spill (filter (flip elemRegSet (on_stack live)) fs) ++
|>> map reload (uniqSetToList (kill fs (in_regs live))) of
|>> [] -> Nothing
|>> reloads -> Just $ mkMiddles (m : reloads)
|>>
|>> So, if I understand this code correctly, it unilaterally reloads
|>> /anything/ in the registers according to the analysis at that point.
|>>
|>> Well, I could see that resulting in the behavior below.
|>>
|>> It's not so clear to me what the correct rewrite is; according to
|>> Marlow's comment on IRC, we ought not to be spilling/reloading foreign
|>> calls yet, so maybe the whole bit should get excised? Otherwise, it seems
|>> to me that transfer function needs to accomodate unsafe foreign
|>> functions.
|>
|> Right, there's no need to spill/reload anything around an *unsafe*
|> foreign call in the Cmm code generator. The NCG's register allocator
|> will do any necessary spilling/reloading around foreign calls.
|>
|> Cheers,
|> Simon
|>
|>
|>
|>> Cheers,
|>> Edward
|>>
|>> Excerpts from Simon Marlow's message of Tue Feb 01 03:44:41 -0500 2011:
|>>> On 01/02/2011 00:01, Edward Z. Yang wrote:
|>>>> Current theory:
|>>>>
|>>>> c1jj:
|>>>> _s1ep::I32 = I32[(slot<_s1ep::I32> + 4)]; // CmmAssign
|>>>> _s1fP::I32 = I32[(slot<_s1fP::I32> + 4)]; // CmmAssign
|>>>> // outOfLine should follow:
|>>>> _s1eq::F64 = F64[_s1fP::I32 + 3]; // CmmAssign
|>>>> I32[(young<c1jh> + 4)] = c1jh; // CmmStore
|>>>> foreign call "ccall" arg hints: [PtrHint,] result hints:
|>>>> [] call_fn_blob(...) returns to c1jh args: ([_s1ep::I32,
|>>>>
|>>>> _s1eq::F64]) ress:
|>>>> ([_s1ev::F64]) with update frame 4; // CmmForeignCall
|>>>> c1jh:
|>>>> _s1ev::F64 = F64[(slot<_s1ev::F64> + 8)]; // CmmAssign
|>>>> // emitReturn: Sequel: Assign
|>>>> _s1ev::F64 = _s1ev::F64; // CmmAssign
|>>>> F64[(slot<_s1ev::F64> + 8)] = _s1ev::F64; // CmmStore
|>>>> goto u1Ak; // CmmBranch
|>>>>
|>>>> Note the line immediately after c1jh, where we reload the ostensibly
|>>>> spilled _s1ev back into a register. Except that it was never spilled
|>>>> there in the first place, and we just clobbered the real value. Oops.
|>>>>
|>>>> Is this interpretation correct?
|>>>
|>>> It sounds plausible, but I really have no idea. The code generator does
|>>> not have to generate spill/reloads around foreign calls, the register
|>>> allocator will do that.
|>>>
|>>> Cheers,
|>>> Simon
|>
|>
|
|
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
