- User Since
- Dec 5 2012, 4:53 PM (435 w, 6 d)
Graphics does use region, so we can't break that
Needs some pure MIR tests too (also including negative tests)
This is also further confused by the two types of implicit operands. There are implicit physical register uses as present in the instruction definition, but also implicit uses that code can arbitrarily append to an instruction
I don't think a helper that's only useful in the middle of a partial instruction modification is useful to generally expose
Mon, Apr 12
This is why we should work to migrate to the reverse scavenger which does not depend on kill flags
Sat, Apr 10
Fri, Apr 9
LGTM, although should look into updating the MFI serialization
Thu, Apr 8
If it doesn't make an observable difference, there's no real reason to add the extra check?
Can you add a test for the DBG_VALUE case?
Can we just drop the Is from the bit name?
Wed, Apr 7
I guess it would be nicer
It's really hard to write checks for R600, but it's in maintenance mode. The comment doesn't really make sense to me. I doubt this check was ever really correct or stable. You can't really write this test stably and expect specific things in T registers at a specific time. I guess just go with this is it passes?
Message / name is somewhat confusing since I assumed this meant the scc register
Can't this just skip virtual registers? Does it really need to know which mode its in?
Tue, Apr 6
Mon, Apr 5
Thu, Apr 1
Oh whoops, I forgot the hardware totally ignores the modifiers with IEEE mode on (not that this behavior makes any sense). We can't actually do this
LGTM, although we have a few too many constant lookup functions at this point
Typo tyeps in commit message
Probably should have some unit tests for this
Description is misleading. This should be allow a different type for the offset/width operands, which do not necessarily need to be constant
Wed, Mar 31
If the fallback is enabled, this pass will still run. You need to have the pass check if isel failed and skip the function if it suceeded
I wonder if we should ban this in the verifier. It's not wrong, but it sure feels like bad form to allow cross bank copies involving physical registers
Tue, Mar 30
I guess this is technically correct but I wouldn't spend time getting this accurate
Can this be abandoned now?
I think the block numbering is meaningless and shouldn't be any different between selectors
Is this still needed?
I just realized I've been reading "frame pointer elimination" as "frame index elimination" but this change still doesn't make sense to me. Why do you want to treat these stores as frame instructions when they don't modify the stack pointer?
This seems like a confusion of what frame instructions means. What do these stores have to do with call frames? The stores should reference frame indexes representing fixed frame objects in the incoming arguments or local objects. The frame adjust instructions are for SP modifications in call sequences where instructions are directly referencing offsets off of the SP, which do not have corresponding frame indexes
LGTM. I think "lanes do not die in a function" may not be true in the future, but is good enough for now (not sure whether callers or callees should be responsible for wave termination on kill)
LGTM, though ensuring the right mode in the lowering. We probably won't have MIR atomic expansions anytime soon
Should have isCanonicalize utility function
Implicit operands aren't special. I also think the subreg handling is off
I don't think this should special case statepoints. Any regmask with tied operands should behave the same way
Fix being totally wrong
Yeah, that's wrong