On Tue, Sep 9, 2008 at 10:14 AM, Tim Chevalier <[EMAIL PROTECTED]> wrote:
> Well, one solution, which is not simple but not as complicated as it
> could be, is (just for ExtCore) to inline only names that appear in
> the original source module's export list, under the rationale that
> these are les
On Tue, Sep 9, 2008 at 9:00 AM, Simon Peyton-Jones
<[EMAIL PROTECTED]> wrote:
> But the point is that GHC knows *nothing* about (+) except its type and the
> inlining exposed by GHC.Base.hi. If you changed the definition of (+) at
> Int, and recompiled GHC.Base.hi, then any ExtCore that had inli
| On 9/8/08, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
| > If you want them (as you suggest) to be more like .hs files, then
| indeed you are going to sharply limit the amount of optimisation that
| you can do, by nuking all cross-module optimisation. For example
| (3::Int + 4) will not turn
On 9/8/08, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
> If you want them (as you suggest) to be more like .hs files, then
indeed you are going to sharply limit the amount of optimisation that
you can do, by nuking all cross-module optimisation. For example
(3::Int + 4) will not turn into an ad
| Okay, let me rephrase this more succinctly. I think that the following
| would be a useful principle (even though it's not how things work
| right now): An External Core file that was generated by GHC cannot
| refer to any names defined in standard library files that I would not
| be allowed to r
On 9/8/08, Tim Chevalier <[EMAIL PROTECTED]> wrote:
>
> Maybe I didn't state my point clearly, or maybe it was so obvious as
> to be easily missed. An External Core file should be like a Haskell
> source file at least in the sense that it doesn't depend on any
> strange names that appear in .hi
On Mon, Sep 8, 2008 at 12:29 AM, Simon Peyton-Jones
<[EMAIL PROTECTED]> wrote:
> I think that's a separate question.
>
> I'm saying that if you want to read in a ExtCore file, you'd better not have
> recompiled any of the modules it depends on. But that's true for linking
> too! If A imports B,
| I didn't try it, because I didn't know about that flag. I'll
| experiment with it at some point. But from your other comments, it
| sounds like you're confirming my suspicion that making GHC generate
| External Core files that it can read back in again entails either
| paying an optimization cost
On 9/5/08, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
> Meanwhile -fomit-interface-pragmas should work fine even with -O on, and
> should dramatically trim what shows up in interface files. Did you try that?
>
I didn't try it, because I didn't know about that flag. I'll
experiment with it at
L PROTECTED] On Behalf Of Tim
| Chevalier
| Sent: 04 September 2008 18:06
| To: Cvs-ghc@haskell.org
| Subject: External Core output path
|
| While I'm trying to integrate some additional tools I wrote into the
| ext-core library, I thought I might say a word about why getting GHC
| to read Cor
While I'm trying to integrate some additional tools I wrote into the
ext-core library, I thought I might say a word about why getting GHC
to read Core back in is hard (and I don't think I've mentioned this
before, though I may have forgotten).
When optimization is turned on, or even when it's not,
11 matches
Mail list logo
