Improve code generation for conditionals
Concern Raised6d14c1485cb5

Authored by simonpj on Mar 8 2017, 5:05 AM.


Improve code generation for conditionals

This patch in in preparation for the fix to Trac Trac #13397

The code generator has a special case for

case tagToEnum (a>#b) of
  False -> e1
  True  -> e2

but it was not doing nearly so well on

case a>#b of
  DEFAULT -> e1
  1#      -> e2

This patch arranges to behave essentially identically in
both cases. In due course we can eliminate the special
case for tagToEnum#, once we've completed Trac Trac #13397.

The changes are:

  • Make CmmSink swizzle the order of a conditional where necessary; see Note [Improving conditionals] in CmmSink
  • Hack the general case of StgCmmExpr.cgCase so that it use NoGcInAlts for conditionals. This doesn't seem right, but it's the same choice as the tagToEnum version. Without it, code size increases a lot (more heap checks).

    There's a loose end here.
  • Add comments in CmmOpt.cmmMachOpFoldM
simonmar added inline comments.

@dfeuer @simonpj I just came across this during the GHC meeting today because it was referenced from Trac #13397, which we were talking about.

There's something wrong here: the code pattern matches on MO_Ne and replaces it with MO_Eq, unconditionally.

It's not clear that we want to do that, because we have another optimisation in CmmContFlowOpt that might do the opposite (;838a10fcad9168895b49b4709056b549f2888860$284-305)

I suspect we want to be a bit more specific about what kind of conditionals we munge here.

simonmar raised a concern with this commit.Sep 11 2017, 10:50 AM
This commit now has outstanding concerns.Sep 11 2017, 10:50 AM