RFC notifications bot (Aug 05 2021 at 21:04): RFC notifications bot (Aug 05 2021 at 21:04):cfallin commented on issue #13:
A note to frame things a bit: this pre-RFC contains what I think are a reasonable set of requirements to consider, but the requirements themselves are very much up for discussion, and I'm interested to hear what others think about their relative importance, or if this is missing any important requirements.
The discussion questions in the last part are also what I believe to be relevant design axes to talk about, but there may be others as well; please discuss!
RFC notifications bot (Aug 16 2021 at 14:38):sparker-arm commented on issue #13:
My gut feeling is that using an existing DSL (peepmatic), and having a layer that tries the generated patterns first, falling back to the existing matchers, would provide the lowest barrier to entry for users as well as keeping the build system simple. Any finger in the air guesses how compilation time would be effected against the simple match strategy used currently? I also would wonder whether a DSL for _just__ isel would be a big enough carrot for getting people to port over... Considering the amount of C++ in LLVM used for isel, even though tablegen has been there for as long as I know, should not be underestimated :) So, I feel at least half of tablegens value is the ease in which it enables the encodings to be described and it would be great if we had something like that too.
RFC notifications bot (Aug 16 2021 at 14:38):sparker-arm edited a comment on issue #13:
My gut feeling is that using an existing DSL (peepmatic), and having a layer that tries the generated patterns first, falling back to the existing matchers, would provide the lowest barrier to entry for users as well as keeping the build system simple. Any finger in the air guesses how compilation time would be effected against the simple match strategy used currently? I also would wonder whether a DSL for _just isel would be a big enough carrot for getting people to port over... Considering the amount of C++ in LLVM used for isel, even though tablegen has been there for as long as I know, should not be underestimated :) So, I feel at least half of tablegens value is the ease in which it enables the encodings to be described and it would be great if we had something like that too.
RFC notifications bot (Aug 16 2021 at 14:38):sparker-arm edited a comment on issue #13:
My gut feeling is that using an existing DSL (peepmatic), and having a layer that tries the generated patterns first, falling back to the existing matchers, would provide the lowest barrier to entry for users as well as keeping the build system simple. Any finger in the air guesses how compilation time would be effected against the simple match strategy used currently? I also would wonder whether a DSL for _just_ isel would be a big enough carrot for getting people to port over... Considering the amount of C++ in LLVM used for isel, even though tablegen has been there for as long as I know, should not be underestimated :) So, I feel at least half of tablegens value is the ease in which it enables the encodings to be described and it would be great if we had something like that too.
RFC notifications bot (Aug 17 2021 at 20:52):fitzgen commented on issue #13:
having a layer that tries the generated patterns first, falling back to the existing matchers, would provide the lowest barrier to entry for users as well as keeping the build system simple.
This is the "horizontal" integration in the pre-RFC, and I am inclined to agree, unless the vertical integration happens to fall out of the DSL's compilation/execution model "for free".
Any finger in the air guesses how compilation time would be effected against the simple match strategy used currently?
I wouldn't expect any significant slow downs, assuming that the DSL also compiles down to Rust code similar to what you would otherwise have written by hand (e.g. a
matchthat switches on opcode). Maaaayyyybe a little bit of overhead related to icache because there are now two code paths rather than one, but I wouldn't expect too much.
RFC notifications bot (Aug 17 2021 at 21:02):cfallin commented on issue #13:
@sparker-arm the goal is certainly to generate code equivalent to what we have today, so ideally we have zero slowdown in the Cranelift compile time, and in the future, possibly improvements that are enabled by more centralized control of the backend code's idioms (i.e., right now if we come up with a new way of matching, we have to modify all of the open-coded use sites; but if we generate this from patterns then we can transition instantly). The latter is especially interesting to me as it will let us eventually move to the native SSA-based API of regalloc2 which should give some speedups.
I've got a reasonable design down on paper now and am working on refining the writeup before posting the RFC -- hope to have it up in the next few days :-)
RFC notifications bot (Aug 19 2021 at 05:51):cfallin commented on issue #13:
I will go ahead and close this pre-RFC, as I think it has served its purpose well in starting discussions and getting early feedback on ideas that have gone into a now more fully-formed RFC, #15. Thanks all for the input and please do give any thoughts you might have on the new RFC!
Last updated: Nov 22 2024 at 16:03 UTC