scpmw (Peter Wortmann)
User

Projects

User does not belong to any projects.

User Details

User Since
Jun 6 2014, 1:30 PM (235 w, 4 d)

Recent Activity

Jul 25 2018

Ian Lynagh <igloo@earth.li> committed rGHCDIFF5b5294f40a52: Testcase for objective-c++ compilation (trac #5150) (authored by scpmw).
Testcase for objective-c++ compilation (trac #5150)
Jul 25 2018, 9:32 AM
Ian Lynagh <igloo@earth.li> committed rGHCDIFFe17c1568baf1: Teach GHC to compile objective-c++ files as well (trac #5150) (authored by scpmw).
Teach GHC to compile objective-c++ files as well (trac #5150)
Jul 25 2018, 6:58 AM

Feb 2 2017

scpmw added a comment to D3051: Don't tick top-level string literals.

Wouldn't literal strings always float up to the top level eventually? Always discarding ticks on string literals might be the right thing to do.

Feb 2 2017, 2:55 AM

Jan 31 2017

scpmw added a comment to D3049: FloatOut: Allow floating through breakpoint ticks.

Just to clarify my position: No strong opinion on what should or should not be allowed with breakpoints - I was just trying to get as close as possible to the existing semantics, and have as few special cases as possible.

Jan 31 2017, 6:36 AM
scpmw added a comment to D3037: Improve wrapTicks performance with lots of redundant source notes [#11095].

Some comments. Could change things, but feels like a matter of style at this point.

Jan 31 2017, 5:19 AM

Jan 28 2017

scpmw retitled D3037: Improve wrapTicks performance with lots of redundant source notes [#11095] from to Improve wrapTicks performance with lots of redundant source notes [#11095].
Jan 28 2017, 4:30 PM

Jan 25 2017

scpmw added a comment to D3001: Make tickishContains faster.

Sorry I didn't react in IRC, was away at the time - Debug.cmmDebugGen simply tries to do the same thing on the Cmm-level that happens in mkTick on Core level: Sometimes Cmm optimisation merges blocks, at which point more source notes enter an existing tick scope, and might become redundant in the process. This does not happen often, yet regularly enough that I noticed it in ThreadScope and added this quick fix.

Jan 25 2017, 6:56 AM

Dec 10 2016

scpmw added a comment to D2804: Fix cost-centre-stacks bug (#5654).

Played around with it a bit - seems to be doing mostly the right thing. T5654-O1 does not actually test the problematic case, as CorePrep eta-expands f. Also this seems to not work if we "hide" the PAP in a constructor:

Dec 10 2016, 6:45 AM

Jun 18 2016

scpmw added a comment to D2343: [WIP] llvmGen: Produce debug information metadata for functions.

Good work. Seems LLVM's DWARF representation has matured a bit since I touched it. Adding debug annotations for the blocks shouldn't be that hard either, right? I added a few more or less obvious remarks.

Jun 18 2016, 10:59 AM

Dec 10 2015

scpmw added a comment to D1532: Dwarf: Assume first block in a proc has an info table.

Not quite sure. Normally the DebugBlock of a procedure refers to the entry block itself, so to me this looks like you are annotating the *second* block. Maybe the first block doesn't contain instructions here and gets optimised away?

Dec 10 2015, 6:41 AM

Dec 7 2015

scpmw added inline comments to D1565: Add -ftick-everything to annotate all expressions and binders with ticks.
Dec 7 2015, 6:55 AM · GHC

Dec 4 2015

scpmw added inline comments to D1565: Add -ftick-everything to annotate all expressions and binders with ticks.
Dec 4 2015, 1:03 PM · GHC
scpmw added a comment to D1565: Add -ftick-everything to annotate all expressions and binders with ticks.

Fair enough. The test case might be a bit fragile - maybe just check whether the expected source annotations appear at all?

Dec 4 2015, 4:06 AM · GHC

Nov 26 2015

scpmw added a comment to D1533: Dwarf: Mark GHC-produced code as being a signal handler on x86_64.

Hm, interesting idea. The real question here would be whether there is other behaviour that's attached to this flag...

Nov 26 2015, 1:55 PM

Nov 3 2015

scpmw added a comment to D1387: Dwarf: Ensure tick parentage is preserved.

Good point, optimised-out blocks might be a problem here... Especially because in theory they could have ticks (which are now lost). Maybe it would actually be better to let all blocks through, but omit code pointers for "empty" DIEs? I believe that's valid for DWARF.

Nov 3 2015, 4:19 AM

Oct 31 2015

scpmw added a comment to D1387: Dwarf: Ensure tick parentage is preserved.

Good work. Just two small suggestions, see inline comments.

Oct 31 2015, 4:12 PM

Oct 29 2015

scpmw added a comment to D1369: DWARF: Add debugging information chapter to users guide.
In D1369#40006, @austin wrote:
  1. GHC can generate debug info with '-g'
  2. You can debug it with GDB, here's an example.
  3. You can also profile, too.
Oct 29 2015, 11:56 AM
scpmw added a comment to D1387: Dwarf: Ensure tick parentage is preserved.

It's not quite as simple as this. It's probably best to look at the output of -ddump-debug to see what's going on, but here's roughly what we start with:

Oct 29 2015, 5:35 AM

Sep 28 2015

scpmw added a comment to D1279: Output source notes in extended DWARF DIEs.

Yes, good direction to take this. (Just realised I didn't answer your comment in D1213 - sorry about that.)

Sep 28 2015, 7:34 AM

Sep 10 2015

scpmw added a comment to D1213: [RFC] Core notes.

Currently there's no code even using this, so I presume this is just here for completeness' sake?

Sep 10 2015, 10:08 AM

Sep 4 2015

scpmw added a comment to D1215: [RFC] Statistical profiling infrastructure.
Sep 4 2015, 10:35 AM
scpmw added a comment to D1215: [RFC] Statistical profiling infrastructure.

You are copying the .debug_ghc contents verbatim here? As you are probably aware, my code associated it with DWARF information at this point, also generating event log entries for all other DWARF it could find.

Sep 4 2015, 10:35 AM
scpmw added a comment to D1216: [RFC] StatProfile: Heap and black-hole sampling.

Yeah, the R9 hack is certainly bad. When I originally wrote the code, stg_no_regs was a preprocessor macro, which made it easier in a number of ways.

Sep 4 2015, 9:58 AM

Sep 3 2015

scpmw added a comment to D1197: Signals: Print backtrace on SIGUSR2.

Also might be a good spot to discuss this - is libdwfl's unwinder segfault-proof? Because especially for Haskell code it will be a bit hit-and-miss whether the backtrace succeeds. The code generator only updates the unwind information at the start of the block, so basically anything after an Sp update until the end of the block would be potential crash territory.

Sep 3 2015, 8:37 AM

Sep 2 2015

scpmw added a comment to D1197: Signals: Print backtrace on SIGUSR2.

This actually manages to unwind through the signal handler? Wow.

Sep 2 2015, 4:04 PM
scpmw added a comment to D1196: Libdw: Add libdw-based stack unwinding.

Comments.

Sep 2 2015, 12:24 PM
scpmw added a comment to D1198: Provide DWARF-based backtraces to Haskell-land.

Some small comments...

Sep 2 2015, 12:20 PM

Sep 1 2015

scpmw added a comment to D963: Add Stack Traces in Haskell land based on symtab.

Well, we would add an additional dependencies for a feature that we know to be incomplete. gdb's backtraces are a lot better and completely portable to boot, so the added value would be marginal. Neither is the fault of the Haskell interface, obviously...

Sep 1 2015, 11:45 AM
scpmw added a comment to D1189: [RFC] x86_64: Setup frame pointer for ccalls.

Well, you might not be far off - I am scratching my head a bit too. From looking at that C function it looks like $rsp might get "lost". After all, no unwind rule ever updates it. This doesn't even change when compiling with -fomit-frame-pointers, which definetely should not work. After all, we are computing the CFA for every frame from $rsp, so it cannot stay the same!

Sep 1 2015, 10:44 AM
scpmw added a comment to D1189: [RFC] x86_64: Setup frame pointer for ccalls.

@bgamari: I am a bit confused too - normally unwinding should just replicate exactly what the assembly does. I guess your point is that the C code is sloppy with restoring all registers in its unwind rules?

Sep 1 2015, 4:02 AM

Aug 24 2015

scpmw added a comment to D1156: [RFC] Add libdw-based backtraces.

I think there is a much higher probability that libelf is available than libdw.

Aug 24 2015, 10:20 AM
scpmw added a comment to D1156: [RFC] Add libdw-based backtraces.

The latter case is what prompted me to enter down this rabbit-hole, namely Trac #9221. This bug points out the fact that GHC's -j option scales poorly over large core counts.

Aug 24 2015, 7:54 AM
scpmw added a comment to D1156: [RFC] Add libdw-based backtraces.

I intend to place both @Tarrasch's CodeMap and my libdw backend (and potentially even libbacktrace- or libunwind-based backends) behind some sort of abstraction, allowing us to use whatever stacktrace mechanism is available at compile time. At the moment I'm leaning towards having all of these use the same StackTrace type.

Aug 24 2015, 5:48 AM

Aug 21 2015

scpmw added a comment to D1156: [RFC] Add libdw-based backtraces.

Indeed, I think it actually even has kernel support for this to avoid round-trips to user-space.

Aug 21 2015, 9:41 AM
scpmw added a comment to D1156: [RFC] Add libdw-based backtraces.

Perhaps we should expect the s9Q0_info frame should be pushing the underwinder towards the Haskell stack? @scpmw, what did you intend here?

Aug 21 2015, 9:18 AM
scpmw added a comment to D1156: [RFC] Add libdw-based backtraces.

For instance, perf has stack trace support (might want to check what it uses).

Aug 21 2015, 9:07 AM

Aug 20 2015

scpmw added a comment to D1156: [RFC] Add libdw-based backtraces.

Interesting. A few points:

Aug 20 2015, 11:17 AM
scpmw added a comment to D963: Add Stack Traces in Haskell land based on symtab.
In D963#31819, @bgamari wrote:

@scpmw, have you looked at libunwind? @simonmar recommended it.

Aug 20 2015, 4:35 AM

Aug 19 2015

scpmw added a comment to D963: Add Stack Traces in Haskell land based on symtab.
In D963#31808, @bgamari wrote:

The interface is incredibly simple. This simplicity may rule it out in our case. For one, I'm unsure of is whether it supports dynamic linking at all (the interface just looks too simple for all of this to work automatically). Secondly, it is quite limited in what it offers: it will happily unwind the stack for you, giving you the PC, a symbol name, and source location information as it goes. At first glance this looks perfect, but I'm not sure if we might need more control at some point given the rather tricky mapping from Haskell onto DWARF. @scpmw, perhaps you could comment here?

Aug 19 2015, 10:09 AM
scpmw added a comment to D963: Add Stack Traces in Haskell land based on symtab.
In D963#31774, @bgamari wrote:

@scpmw, concerning your statement,

Original reason for libelf was that it allows us to read more DWARF info using libdwarf, but that could turn out to be irrelevant now.

If I'm not mistaken (which is quite possible), libelf is a library provided by elfutils. The DWARF library provided by elfutils is libdw. libdwarf is an entirely separate project. What did you mean by your statement?

Aug 19 2015, 8:47 AM

Jul 23 2015

scpmw added a comment to D963: Add Stack Traces in Haskell land based on symtab.

Looks okay, nothing big stands out. Really disappointing that we need conditional compilation for libelf though... I would really have hoped that we could avoid that.

Jul 23 2015, 5:14 AM

Jun 28 2015

scpmw added a comment to D963: Add Stack Traces in Haskell land based on symtab.

Some users might want need many stack traces to be reified all the time (imagine a web server that shows stack trace on 404).

Jun 28 2015, 4:35 AM

Jun 24 2015

scpmw added a comment to D963: Add Stack Traces in Haskell land based on symtab.

In my opinion, the CodeMap bits shouldn't become public API in the first place. GHC shouldn't expect the Haskell code to make its memory management decisions. Are we really sure that we have a usage scenario for all that? Can't we get around it using - say - finalisers?

Jun 24 2015, 1:49 PM

Jun 9 2015

scpmw added a comment to D963: Add Stack Traces in Haskell land based on symtab.

The Haskell module interface needs work in my opinion. Apart from that - what does it look like in the end? Did you try this for anything of non-trivial size?

Jun 9 2015, 8:36 AM

Apr 21 2015

scpmw added a comment to D661: rts: Add Stack.c and accompanying rtsflags.

Sorry, not yet. Do you need it to make progress?

Apr 21 2015, 3:42 AM

Apr 2 2015

scpmw added a comment to D792: Restore unwind information generation.

Valid concern, though a bit tricky. Ideas, ordered from "easiest to do" to "catches most mistakes":

Apr 2 2015, 2:43 PM

Feb 26 2015

scpmw added a comment to D662: Haskell land Stack Traces proposal.

@Tarrasch: I won't be able to do anything substantial until after next week. If you want to have a stab at it, go ahead.

Feb 26 2015, 4:52 PM

Feb 25 2015

scpmw added a comment to D662: Haskell land Stack Traces proposal.

@tibbe: For this patch, reifyStack basically walks the stack and copies found return addresses into a buffer. That's obviously a O(n) operation (even if we introduce a bound), which could be undesirable for exceptions.

Feb 25 2015, 3:39 AM

Feb 22 2015

scpmw added a comment to D661: rts: Add Stack.c and accompanying rtsflags.

We should probably find some sort of proper intermediate goal to work towards... D661 does pretty much nothing, so it's hard to argue about. On the other hand, D669 does a lot that we probably don't want, so it's not very useful as a starting point for a discussion either.

Feb 22 2015, 11:51 AM

Feb 9 2015

scpmw added a comment to D616: Retain cost-centre ticks on floated-out partial function applications.

Something like that. The main observation is that the places we may need to do this correspond exactly to thunks, which already have update frames and indirection objects. Thunks that evaluate to functions are where we need to capture the CCS being returned and remember it, for use when the function is applied.

Feb 9 2015, 10:36 AM

Feb 4 2015

scpmw added a comment to D616: Retain cost-centre ticks on floated-out partial function applications.

I agree, Trac #5654 looks like the same issue. My changes probably have just brought it to light.

Feb 4 2015, 8:34 AM

Jan 30 2015

scpmw updated the diff for D616: Retain cost-centre ticks on floated-out partial function applications.

Okay, here's the updated test case. D636 in concert with unfolding just happens to undo the damage that floating does - if we can get the expression to stay floated (for which we need to prevent eta-expansion completely), the bug is still present.

Jan 30 2015, 6:59 AM

Jan 29 2015

scpmw added a comment to D616: Retain cost-centre ticks on floated-out partial function applications.

Okay, here's what I *think* GHC is doing:

Jan 29 2015, 6:08 AM

Jan 27 2015

scpmw added a comment to D616: Retain cost-centre ticks on floated-out partial function applications.

Hm, good point - your semantics indeed update CCS on lambda values. So the semantics disagree on expressions that evaluate to lambda values, but are not lambda expressions themselves. Interesting.

Jan 27 2015, 4:13 AM

Jan 20 2015

scpmw requested review of D616: Retain cost-centre ticks on floated-out partial function applications.

(Er, misunderstood what "without requesting a code review" meant. Thought it would prevent unnecessary notifications. Seems it does the opposite...? Sorry about that.)

Jan 20 2015, 1:09 PM
scpmw planned changes to D616: Retain cost-centre ticks on floated-out partial function applications.
Jan 20 2015, 12:53 PM
scpmw updated the diff for D616: Retain cost-centre ticks on floated-out partial function applications.

(typo fix)

Jan 20 2015, 12:53 PM
scpmw updated the diff for D616: Retain cost-centre ticks on floated-out partial function applications.

Added test case. I am not quite sure how to force GHC to float out an expression - using (1+1) as parameter was the easiest way I could find.

Jan 20 2015, 11:15 AM
scpmw added a comment to D616: Retain cost-centre ticks on floated-out partial function applications.

This should be fine, except that we'll now eliminate the scc on z. I think that eliminating the scc on z may be wrong in this case.

Jan 20 2015, 5:29 AM

Jan 18 2015

scpmw added a comment to D616: Retain cost-centre ticks on floated-out partial function applications.
  • The PAP will be called from inside the SCC, so the resulting stack will be the same as before
Jan 18 2015, 4:44 PM

Jan 14 2015

scpmw added a comment to D616: Retain cost-centre ticks on floated-out partial function applications.

This is sort-of what happens. Except that it would tick the parameter (tickHNFArgs) and remove the scoping portion from z, as it's now a plain variable. This means that we end up with something like:

Jan 14 2015, 5:26 PM

Jan 12 2015

scpmw updated D616: Retain cost-centre ticks on floated-out partial function applications.
Jan 12 2015, 11:34 AM
scpmw updated D616: Retain cost-centre ticks on floated-out partial function applications.
Jan 12 2015, 11:23 AM
scpmw retitled D616: Retain cost-centre ticks on floated-out partial function applications from to Retain cost-centre ticks on floated-out partial function applications.
Jan 12 2015, 11:20 AM

Dec 19 2014

scpmw accepted D580: dwarf: sync getIdFromTrivialExpr with exprIsTrivial (test break028 and others).

This was already reported in #ghc (possibly same person?) and is actually already corrected in my local branch. So, yeah :)

Dec 19 2014, 5:37 PM

Dec 17 2014

scpmw added a comment to D396: DWARF generation.

I was referring to the fact that we can't link against it for most common distributions, as well as that it depends on libelf to the point that it's entirely useless on anything but Linux. The only realistic shipping option would be to ship a patched version, which is probably something we'd like to avoid.

Dec 17 2014, 7:01 AM

Dec 16 2014

scpmw abandoned D396: DWARF generation.

(landed as multiple commits)

Dec 16 2014, 6:48 PM
scpmw abandoned D169: Source Note Core Infrastructure.

(landed as multiple commits)

Dec 16 2014, 6:48 PM
scpmw added a comment to D396: DWARF generation.

@Tarrasch - this doesn't talk about line numbers explicitly at any point, we leave that to the assembler. You are probably referring to the .debug_ghc records, which aren't yet part of this.

Dec 16 2014, 4:58 AM
scpmw updated the diff for D396: DWARF generation.

Rebased, following D169.

Dec 16 2014, 4:42 AM

Dec 15 2014

scpmw updated the diff for D169: Source Note Core Infrastructure.

Rebased, omit failing tests.

Dec 15 2014, 7:45 PM
scpmw added a comment to D169: Source Note Core Infrastructure.

By the way - arc will squash all this into a single commit by default, right? That would be a shame, as I made sure to structure everything into steps, which was really useful when tracking down bugs and performance regressions. For reference, my arc branch is available on GitHub.

Dec 15 2014, 12:57 PM
scpmw updated the diff for D169: Source Note Core Infrastructure.

Fixed another rare Core change with annotations found by the testsuite

Dec 15 2014, 12:31 PM

Dec 11 2014

scpmw updated the diff for D169: Source Note Core Infrastructure.

Added debug test

Dec 11 2014, 9:38 AM

Dec 10 2014

scpmw updated the diff for D396: DWARF generation.

Made consistent with new revision of D169, fixed lint and corrected
yet another performance test.

Dec 10 2014, 5:04 AM

Dec 8 2014

scpmw added a comment to D169: Source Note Core Infrastructure.

Does that mean T4801 is failing, or not?

Dec 8 2014, 10:54 AM
scpmw added a comment to D396: DWARF generation.

Yeah, I'll have to change a few things because of the changes in D169 anyway. Won't take too long, hopefully.

Dec 8 2014, 9:43 AM

Dec 7 2014

scpmw added a comment to D169: Source Note Core Infrastructure.

Okay, this one passes validate for me, and especially all performance tests. T4801 fails depending on build parameters, apparently due to the extra field in MkCgInfoDown.

Dec 7 2014, 12:50 PM
scpmw updated the diff for D169: Source Note Core Infrastructure.

Fixed lints and test cases, some tick scopes refactoring.

Dec 7 2014, 11:56 AM

Dec 5 2014

scpmw added a comment to D169: Source Note Core Infrastructure.

Yes, I'm aware. @austin told be that he'd still merge once it passes the tests. Trickiest part is still to get the performance tests running (still without -g). Current status:

Dec 5 2014, 5:07 AM

Dec 3 2014

scpmw added a comment to D155: llvmGen: Compatibility with LLVM 3.5.

You are referring to your blog post, I presume? Not too keen on leaving the symbols external - are we sure this won't cause problems when names collide? Maybe just do it for LLVM 3.4, if we really must?

Dec 3 2014, 4:09 AM

Nov 28 2014

scpmw added a comment to D530: llvmGen: move to LLVM 3.6 exclusively.

Good initiative! This would make our life easier indeed. The real question is probably whether the LLVM change will go through? After all, from their point of view this is probably yet another extension that only GHC will ever use...

Nov 28 2014, 4:35 PM

Nov 23 2014

scpmw added a comment to D169: Source Note Core Infrastructure.

Do these tests fail only with -g, or also without -g? (if the latter, I'm more worried)

Nov 23 2014, 5:16 PM

Nov 22 2014

scpmw added a comment to D155: llvmGen: Compatibility with LLVM 3.5.

Uh, sorry, wanted to get a closer look at that build error before I say something. I now had a chance to check the LLVM 3.4 behaviour - apparently what is happening here is (indeed) exactly what I had before. Except that for LLVM 3.4 setting the definition as "used" seemingly doesn't suffice to protect it.

Nov 22 2014, 12:49 PM

Nov 17 2014

scpmw added a comment to D169: Source Note Core Infrastructure.

Sure, working away at it... Don't want to break more than strictly necessary. Some minor notes:

  • Arc keeps complaining about going over 80 columns, are we taking that literally?
  • Also strange to have to give "excuses" for not fixing file endings. After a few revisions I caved now and added the magical newline to UnariseStg.lhs. Not sure this is a good idea - it should probably be a separate patch?
  • Not quite sure what Harbourmaster is trying to tell me, it always fails with strange errors - clearly I am declaring an Ord instance for RealSrcSpan?
  • The patch has grown quite a few trivial changes now. Had I known that splitting up patches in Arc is actually quite easy, I would probably have done that right away. If anybody wants to see the break-down, here's my branch on GitHub: https://github.com/scpmw/ghc/commits/profiling-arc-169
Nov 17 2014, 6:33 AM
scpmw updated the diff for D169: Source Note Core Infrastructure.

Stabilisation...

  • Properly creating multiple tick types at the same time needed quite a bit more plumbing.
  • Changed diffExpr so it matches by Core and IdInfo instead of just Core. Actually ran into a case where the Core was identical but IdInfos were different...
  • Fixed cost centre placement - they shouldn't be reordered relative to each other. Also fixed some extra scc annotatations getting added to bindings.
Nov 17 2014, 2:29 AM

Nov 2 2014

scpmw added a comment to D155: llvmGen: Compatibility with LLVM 3.5.

Hm, interesting - I can reproduce the problem @spacekitteh mentions with and without the patch, as well as with GHC 7.8.3 and 7.6.1. It is gone for GHC 7.4.2, as well as for a random 7.7 version I had lying around (mid 2013). The latter has LLVM streaming (my first suspicion), so the bug must be something different here.

Nov 2 2014, 11:21 AM

Oct 29 2014

scpmw retitled D396: DWARF generation from to DWARF generation.
Oct 29 2014, 1:57 PM

Oct 28 2014

scpmw updated the diff for D169: Source Note Core Infrastructure.

Rebased to HEAD (and a few code style fixes)

Oct 28 2014, 2:20 PM

Oct 25 2014

scpmw added a comment to D155: llvmGen: Compatibility with LLVM 3.5.

Had another look at this - good news is that it seems to be compatible with LLVM versions down to 2.8 (which is as far as we care).

Oct 25 2014, 8:50 AM

Oct 23 2014

scpmw updated D169: Source Note Core Infrastructure.
Oct 23 2014, 10:18 AM

Oct 15 2014

scpmw added a comment to D169: Source Note Core Infrastructure.

Okay, here's what I currently have. Good news is that I was closer to resolving the remaining lint warnings than I thought - after taking another good look at them I realised I actually already knew how to fix them. So now we have a 100% Core match.

Oct 15 2014, 11:27 AM
scpmw updated the diff for D169: Source Note Core Infrastructure.

Added a linting step that actually checks annotation transparency for Core passes (not CorePrep, Stg or Cmm yet!). Resolved all warnings from GHC+library compilation.

Oct 15 2014, 10:56 AM

Oct 9 2014

scpmw added a comment to D169: Source Note Core Infrastructure.

Current status is that linting works out almost too well: It has managed to spot quite a few instances where intermediate Core is different with annotations. I probably didn't see them earlier because annotated and un-annotated compilation converged to the same code anyway for nofib. Solving these is great for confidence - but on the other hand quite a time sink. After all, every divergence involves quite a bit of cat-and-mouse across the compiler to find the bad code. I must admit I still average around half a day of investigation to track one down.

Oct 9 2014, 8:34 AM

Oct 2 2014

scpmw added a comment to D155: llvmGen: Compatibility with LLVM 3.5.

Just as a quick bump - even though I'm mainly preoccupied with D169, I have not forgotten about this. The new aliases definitely survive optimisations, which makes it slightly dangerous. As it happens, on my computer some regular expression in the Mac Os splitter actually chokes on the new $def labels that now appear in the assembly. I'll have to investigate that a bit more.

Oct 2 2014, 1:24 PM

Sep 27 2014

scpmw added a comment to D169: Source Note Core Infrastructure.

Haha - yes, after a lengthy vacation and PhD viva craziness I'm again actively working on it. I agree with most points raised so far, which unfortunately gives me quite a bit to work on. Especially the documentation bits.

Sep 27 2014, 7:28 AM

Aug 25 2014

scpmw added a comment to D169: Source Note Core Infrastructure.

So far this diff is only the "core" changes. This doesn't include actual DWARF generation, let alone profiling code (which tibbe's error is from). I will correct it anyway, as rtsBool is clearly the wrong data type there.

Aug 25 2014, 10:41 AM

Aug 21 2014

scpmw added a comment to D169: Source Note Core Infrastructure.

No, not yet - and in fact until recently there was a problem with selector thunk detection, which was a performance-criticial Cmm issue. There are also a few cases where I had decided against a 100% Cmm match in the interest of profile accuracy. For example, not using canned closure code means that we have more information about where the code in question was generated from, without actually risking too much runtime overhead (from what I understand).

Aug 21 2014, 5:30 PM
scpmw updated the diff for D169: Source Note Core Infrastructure.

Fixed some warnings

Aug 21 2014, 2:06 PM
scpmw updated the diff for D169: Source Note Core Infrastructure.

Removed spurious file and references to CoreNote

Aug 21 2014, 12:23 PM