Krasimir Angelov wrote:
> How mod is affected by the change in quot? Currently mod is defined as:
>
> a `mod` b
> | b == 0 = divZeroError
> | a == minBound && b == (-1) = overflowError
> | otherwise = a `modInt` b
>
> and modInt is defined
How mod is affected by the change in quot? Currently mod is defined as:
a `mod` b
| b == 0 = divZeroError
| a == minBound && b == (-1) = overflowError
| otherwise = a `modInt` b
and modInt is defined via remInt# which is primitive. Did you
Krasimir Angelov wrote:
> Well I actually did, almost. I added this function:
>
> quotX :: Int -> Int -> Int
> a `quotX` b
>| b == 0 = error "divZeroError"
>| b == (-1) && a == minBound = error "overflowError"
>| otherwise = a `quotInt` b
>
> It d
Well I actually did, almost. I added this function:
quotX :: Int -> Int -> Int
a `quotX` b
| b == 0 = error "divZeroError"
| b == (-1) && a == minBound = error "overflowError"
| otherwise = a `quotInt` b
It does the right thing. However to be sure th
Hello Krasimir,
Friday, February 20, 2009, 11:00:30 AM, you wrote:
> and this is exactly what we get. I bet that if the original function was:
well, you check this yourself! :)
--
Best regards,
Bulatmailto:bulat.zigans...@gmail.com
___
I think that what happens is that this function:
a `quot` b
| b == 0 = divZeroError
| a == minBound && b == (-1) = overflowError
| otherwise = a `quotInt` b
is expanded to:
a `quot` b =
if b == 0
then divZeroError
else if a == minBou
On February 19, 2009 18:20:33 Krasimir Angelov wrote:
> Oh. I looked at the primops.txt.pp for something suspicious but I
> didn't checked the actual implementation of quot. I thought that quot
> calls quotInt# directly. When I use quotInt in the code I can get the
> real idiv assembly instruction.
Oh. I looked at the primops.txt.pp for something suspicious but I
didn't checked the actual implementation of quot. I thought that quot
calls quotInt# directly. When I use quotInt in the code I can get the
real idiv assembly instruction. Still the code generated by GHC is
strange it doesn't throw a
2009/2/19 Krasimir Angelov :
> I was surprised to see this case expression:
>
>>case GHC.Prim.-# 9223372036854775807 ipv_s1bD
>>of wild2_a1xi [ALWAYS Just L] {
>
> What is the purpose to compare the value with maxBound before the
> division? The case expression doesn't disappear eve
I was surprised to see this case expression:
>case GHC.Prim.-# 9223372036854775807 ipv_s1bD
>of wild2_a1xi [ALWAYS Just L] {
What is the purpose to compare the value with maxBound before the
division? The case expression doesn't disappear even if I use quot
instead of div.
Krasim
On February 18, 2009 12:42:02 Tyson Whitehead wrote:
> On February 18, 2009 04:29:42 Max Bolingbroke wrote:
> > Yes - GHC wants to share the work of (maxBound-x)`div`10 between
> > several partial applications of "digit". This is usually a good idea,
> > but in this case it sucks because it's resul
On February 18, 2009 04:29:42 Max Bolingbroke wrote:
> > The part of the code under the first lambda in digit is as follows (I
> > didn't keep the original dump, so the uniques have changed here). It's
> > the second part of the Int overflow bounds check (i.e., y <=
> > (maxBound-x)`div`10), and,
2009/2/18 Max Bolingbroke :
> Yes - GHC wants to share the work of (maxBound-x)`div`10 between
> several partial applications of "digit". This is usually a good idea,
> but in this case it sucks because it's resulted in a massively
> increased arity. IMHO GHC should fix this by:
> * Marking divInt#
2009/2/18 Tyson Whitehead :
> On February 17, 2009 19:24:44 Max Bolingbroke wrote:
>> 2009/2/17 Tyson Whitehead :
>> > (compiled with ghc 6.10 with options -O2 -ddump-simpl)
>
> That should have been -ddump-stranal instead of -ddump-simpl.
Right. Mystery solved. In case you were wondering, the rea
On February 17, 2009 19:24:44 Max Bolingbroke wrote:
> 2009/2/17 Tyson Whitehead :
> > (compiled with ghc 6.10 with options -O2 -ddump-simpl)
That should have been -ddump-stranal instead of -ddump-simpl.
> > I was wondering why lvl_s1mF is not being inlined into a_s1Gv in the core
> > at the bott
On February 17, 2009 19:24:44 Max Bolingbroke wrote:
> 2009/2/17 Tyson Whitehead :
> > It also seems the extra levels of indirection are defeating the
> > strictness analyzer on eta_s1CN in a_s1Gv as all code branches either
> > directly force it or ultimately pass it to digit_s1l3 as in the includ
2009/2/17 Tyson Whitehead :
> (compiled with ghc 6.10 with options -O2 -ddump-simpl)
>
> I was wondering why lvl_s1mF is not being inlined into a_s1Gv in the core at
> the bottom of this email as that is the only place it is ever referenced.
The relevant GHC code is SimplUtils.preInlineUncondition
(compiled with ghc 6.10 with options -O2 -ddump-simpl)
I was wondering why lvl_s1mF is not being inlined into a_s1Gv in the core at
the bottom of this email as that is the only place it is ever referenced.
It also seems the extra levels of indirection are defeating the strictness
analyzer on et
18 matches
Mail list logo
