These are inserted after branch relaxation, and for some reason it's
decided to put them in the long branch expansion block. It's probably
not great to rely on the source block address, so this should probably
be switched to being PC relative instead of relying on the block
address
Details
- Reviewers
kzhuravl scott.linder
Diff Detail
Event Timeline
Are the function attributes in the test necessary? Watching other reviews leads me to believe these are undesirable. Apart from this it LGTMy untrained eyes (I'm new to reviewing!).
They're part of the intrinsic declarations, so they're really there either way. I usually leave the ones part of the intrinsic definition
FWIW they're fine IMO too :)
Testcase and match seem a little long - any chance of shrinking either?
This is as far as I was able to get for an IR test. Any further probably requires a MIR testcase. However, the MIR printer and parser don’t correctly handle debug info references in DBG_VALUE. I discovered recently it mostly works if you strip out all the operands to them, but I’m not sure that will work here. I assume the pass reinserting these actually needs the operands to get the same position
I could do a MIR test that only runs the asm printer, which will be less useful whenever the long branch expansion is fixed
Looks ok to me. Are you worried about the correctness of the code? That seems to be a lot of matching?
It's just the autogenerated checks, which check everything. I'm worried about something changing whenever I get around to fixing the long branch expansion, and matching all of the long branch blocks is pretty annoying.
Sure. I'd have probably just checked for the function and maybe an instruction or two rather than the whole thing. It's more fragile that way and harder to understand what you're actually checking for since you mostly just said "doesn't crash" :)