- User Since
- Nov 16 2012, 6:02 PM (274 w, 3 d)
Thu, Feb 15
Mon, Feb 12
Fri, Feb 9
Thu, Feb 8
Wed, Feb 7
Thu, Feb 1
A couple comments, but otherwise LGTM.
Tue, Jan 23
Jan 17 2018
In part, it looks like you're looking to modify heuristics that prevent increased spilling around calls. I can imagine that, in general, architectures with lots of registers suffer from less of that, but that's really a statement about the ABI of the call, not the architecture itself.
Jan 16 2018
Jan 15 2018
Jan 12 2018
Jan 8 2018
Jan 7 2018
If I'm right about the easy FP cases, I'd like to see those handled in follow-up. Regardless, this LGTM.
Jan 6 2018
In this case the intrinsic returns i1 and the legalization promotes it to i32, but we need to return an i1, to insert a truncate back to i1. The new truncate will get added to worklist and end up being legalized itself, but won't require custom legalization.
I'm not sure this is the right fix; it seems like I'm working around the underlying issue rather than actually solving it.
Are you planning to soon introduce an asm parser and disassembler so that you can test the encodings? I recommend doing this early do that you can test those along the way.
Jan 5 2018
Jan 4 2018
Jan 3 2018
Dec 29 2017
Dec 28 2017
Doing this so early on means that we can't recognize common, direct patterns in terms of select. While perhaps it would be better to go and teach everything to generically reason about either a select or a phi around control flow, that will need a really massive undertaking.
Dec 21 2017
It looks like we could do a similar thing in visitCmpInst too (and visitCallSite, however, we'd also need to fix the FIXME about interface inefficiency in CallAnalyzer::simplifyCallSite first?).
Why don't we just cap all names at some point (and then just start adding numbers as we generally do to break degeneracies). It seems like, otherwise, we'll end up with these kinds of fixes in many places. Fixing this in one common place seems better. I'd be much happier, for example, to see a change in lib/IR/Value.cpp where we have:
Dec 20 2017
LGTM. The array accesses here are just being represented as their scalar-access types. In the future, we should update this to represent them as fields in their parent structs, but this is fine for now.
Refactoring this to move the std::function wrapping into once place (as opposed to repeating it in all backends) seems like a good step in general.
Dec 19 2017
I looked into trying to add a 512-bit register feature that could be disabled instead like D41096 proposed, but I couldn't find a good way to make the existing command line options work. The tablegen generated subtarget feature system just doesn't allow for a wrapper/alias feature that implies other features.
LGTM, however, the testing here is fairly light. We should have some cases where we do perform the if conversion because of the DependenceChainLatency check, where we do perform the if conversion because of the IPC check, and because of the BB size check. Also, where the if-converted block has some non-trivial adjustment because of LatencyAdjustment.
Dec 18 2017
LGTM as well.