- User Since
- Jun 5 2014, 11:10 PM (231 w, 5 d)
Mon, Nov 5
worth noting that https://phabricator.haskell.org/D4781 is the better fix
Sat, Oct 27
instead of all mac builds
we could set it to only be MAC AND GCC
@bgamari can we revisit this:
Fri, Oct 26
- tweak language in one documentation comment
- fixing up imports
- remove the memory manipulation pieces
- remove the memory manipulation pieces
need to fix the unsafePrimToPrim $ copyBytes and unsafePrimToPrim $ moveBytes codes
also i'm not sure what code would actually benefit from this addition in base / ghc / user space,
i full expect it to not type check because I put this together on my little laptop so i didn't run a build, but wanted to just get this out ther
Jul 24 2018
This just looks like Michal T's patch ... not the work for simd ONTOP of his patch ... i think you did the arc command line interface wrong...
Jul 9 2018
just did a first passs on the latest changes, though only made my way through the first 50% :)
Jul 6 2018
Abi: This seems to be because we currently conflate the "type/represenation" with the physical registers at the CMM level ?
Jun 27 2018
additionally: you're gonna want to add an IntSIMD# type, because the GPR / R*X / normal int pointer registers and the XMM / YMM / ZMM registers can only communicate via a read/write to memory
(recent ghc has built in a version of https://github.com/cartazio/random/blob/22a2a16bd62edd553b4f7f2e9eedc26cbf8850d8/cmmbits/floatsAndBits.cmm#L10)
as an out of band/explicitly CMM primop.
, theres some confusing design choices in heres
Jun 22 2018
Jun 19 2018
not sure about some bits, but heres some more thoughts
to clarify: ghc currently has no understanding of int/word can be in xmm register.
umm, perhaps this should be folded in the work abhiroop is doing?
why do we have a normal CMM expression changing how we do code gen, this seems deeply wrong to me.
Jun 18 2018
Jun 7 2018
most of the feedback from last time still applies, looks mostly the same, also no tests! fix that soon
Jun 4 2018
i think it might be worth poking at https://phabricator.haskell.org/D4475 and getting it in shape for perhaps ghc 8.8 as a prerequisite for this set of work to have the right internal data model
Theres no tests! (even though we can't run them yet, lets write some tests!)
Jun 3 2018
I can confirm this patch works for me :)
@Abhiroop when the intel docs say the args are xmm1 xmm2 and xmm3, they dont mean those specific registers, they mean "x y z are the args, and theyy're all xmm registers",
I think this confusion came up a few times when we spoke? and I didn't understand at the time what was causing it. :)
I did a rebuild with only these files patched and the build succeeded!
May 23 2018
I'm pretty unfamiliar with the type checker sub system, but i think i spotted 1-2 possible typos/spurious edits/places that might need additional clarity
Jan 28 2018
I guess one question is why are we implicitly the list this way. Seems like a tricky way to specify the register ranges. We know what platforms windows is ... right?
Mar 11 2017
Is it correct to say unsupported ? Seems more like it should be an impossible error for those cases. Cause you're just generating it early.
The not changes the meaning of this not/ the tone thereof .. should it be styled that way or keeping the original language and explaining the corner cases as a new paragraph
- where's definition of pure?
- I'm not sure if the new comments are enough ... should document the ways it should work / preconditions.
- this change is for master or 8.2? I'm guessing master ?
Feb 25 2017
these cross compiling notes are specifically for registerized builds? and or does configure autodetect if the right x-compile tools are around?
Feb 10 2017
i think a cleaner approach might be to add Float 32 and Double 64 bit wise operations (and the associated Data.Bits instance) and use the same machinery to define fabs and fabsf
Feb 9 2017
overall looks decent, just some cleaning still needed :)
Feb 6 2017
i think that we need to discuss what foreignPrimops mean, and or have that metadata be accurate per target architecture
We shoudln't have fabs primops be marked as foreignCalls when they're not always.... we can do CPP in the primops.pp.txt file right?
Feb 2 2017
looks like in some cases this change *could* be a regression, or at least its not clear that its a win to make it a foreign call vs doing the suitable bitwise and masking as Reid and I have discussed
Jan 6 2017
i was thinking of https://ghc.haskell.org/trac/ghc/ticket/12463, which seem to have not been implemented ever, or something like it
Additionally: one possible library that could be a stress test for this would be the vector-algorithms library, which I think currently does very very aggressive in lining to make sure specialization happens
How is this similar or different from specializable pragma? Does this replace needing that on newer ghc?
Nov 12 2016
this looks reasonable to me (otoh I'm not super familiar with the linker code base)
Sep 18 2016
I had to revert this patch / change set on OSX to get my build to succeed.
Aug 3 2016
Is there a follow up patch or design plan for adding Haskell level siblings?
Jul 29 2016
Hrmm, these should be added to the Haskell layer primops too. With suitable state# token arguments similar to other pointer ish based read and write ops
Sweet! Does this mean uses of cas in the rts and user space won't have that extra function call indirection ?
Jul 27 2016
point being: something needs to be done so that handling this corner case, while it exists, isn't a folklore / googling around issue. and its not someting that most folks even are aware of!
Something needs to be done to address this, because otherwise its making build from source for new contributors on OSX even more second class than it already sometimes is :)
May 6 2016
whats needed to move this or something similar to this along?
Apr 17 2016
Looks reasonable to me. (Though I'm not especially knowledgable in c matters)
Off the cuff this looks fine, I may finally get around to sacrificing one of my personal machines to the upgrade gods so I can test that this afternoon.
Apr 2 2016
Sorry, I meant to ask , will this make it into 8.0?
If my understanding is correct it would make a big difference in build time for th heavy code , right ?
Mar 31 2016
Is this one of the changes that is going to land In rc3?
Mar 25 2016
So if I built ghc 8 branch with gcc 5/6 before this patch , there's potentially some perf regressions? How would I measure or isolate that / what programs would make it observable ?
Mar 24 2016
Question: am I correct in understanding that stable pointers only get freed during GC, but that the table itself is not on the heap?
May 6 2015
Apr 25 2015
thanks ben, that clarifies things for me!
Apr 22 2015
am i correct in understanding that the notion of call stack thats in this patch is specifically / only the Profiling build notion of call stack?
Mar 8 2015
Dec 23 2014
did a quick build on OS X, HEAD seems to bulid fine with this patch
Dec 13 2014
Looks good to me. (at least the build systems changes)
Dec 6 2014
did the changes as suggested.
- updating comments and haddocks per Austin's suggestions
Dec 4 2014
though that wiki page has some out of date bits
huh, maybe the readme should just link to https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources ?
Nov 30 2014
probably should add some remarks in the release notes section of the manual for this
Nov 28 2014
Davean and I did some benchmarks (mentioned in the thread here )https://www.haskell.org/pipermail/ghc-devs/2014-November/007458.html
- adding more commentary about the current prefetch designs and why they need to be marked as has_side_effects=True
its worth noting that harbor master currently doesnt do a validate using llvm backend, so we cant test this on phab yet, right?
Nov 26 2014
we can at least make sure / keep an eye on making 3.6 work with 7.10 right?
Nov 25 2014
one support issue that will come up is that the current Xcode release of Clang doesn't support the full range of assembly that LLVM 3.5 emits, (though a built of the official llvm 3.5 CLANG works fine)
- adding has_side_effects to all the prefetch ops everywhere
Nov 24 2014
- fixing typo in test
i think this is ready to go!
- adding something extra to the test suite
Nov 23 2014
ok, marking prefetchValue has has_side_effects=True saves the day
- mark prefetchValue as has_side_effects = True
i seem to have discovered a problem wrt let/app invariant with the api / semantics i have for prefetch value. However, I only seem to get the problem to happen locally on my mac (though I cant even run validate locally for other reasons i can't yet track down).
- add dcore-lint and O1 flags to test case trip the problem i've hit
how on earth is this validating?
- fixup prefetchValue0# and make the tests not depend on vector
i was doing some sanity checking locally, and its pretty clear that the test file wasn't being run by validate somehow (as in, theres no way it compiled, i'm fixing that locally and hopefully things will then be OK)
- use switch \ _ -> with \ _arity ->
- the prefetchValue operations should be lazy in their value argument
i'm concerned that the prefetchValue operations dont have the right strictness information on them. The value argument shouldn't be evaluated.
- Revert "somehow how i modified the docs made the primops file parser fail. twiddling that"
- Revert "clarify documention to make it clear that inlinePerformIO is safe to use here"
- clarify documentation about prefetch
- somehow how i modified the docs made the primops file parser fail. twiddling that
- clarify documentation to make it clear that inlinePerformIO is safe to use here
agreed, should I change the recommendation to unsafeDupable or inlinePerformIO?
and just to be clear, it has a test!
- fixing up some validate -werror noise