Opened 4 years ago

Last modified 2 years ago

#10922 new bug

String inlining is inconsistent

Reported by: xnyhps Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.10.1
Keywords: strings Cc:
Operating System: Unknown/Multiple Architecture: x86_64 (amd64)
Type of failure: Runtime performance bug Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

I have the following code:

A.hs:

module A where

foo :: String
{-# INLINE foo #-}
foo = "foo"

B.hs:

import A

main = if foo == "foo" then return () else putStrLn "Wrong"

Compiling this with -O2 shows the if-statement has not been eliminated ("Wrong" is still part of the output with -ddump-simpl).

However, if I rewrite the code to:

A.hs:

module A where

foo :: () -> String
{-# INLINE foo #-}
foo () = "foo"

B.hs:

import A

main = if foo () == "foo" then return () else putStrLn "Wrong"

Then the if-statement disappears and the generated Core has no string literals left.

Even when the literal can not be eliminated from B it seems GHC is fine with duplicating it accross two modules if it occurs somewhere inside a function. But once I make it a top-level expression of type String, inlining it does not happen. I can not think of how this could be working as intended.

(The case where A.foo is "" seems to work differently, but also does not get optimized away.)

(This happened to me when rewriting some code that previously used CPP for conditional compilation to using if System.Info.os == "darwin" then ... else ... and expecting the other OS cases to get optimized away.)

Change History (1)

comment:1 Changed 2 years ago by bgamari

Keywords: strings added
Note: See TracTickets for help on using tickets.