- User Since
- Jul 18 2017, 7:08 AM (83 w, 3 d)
Tue, Feb 19
Thu, Feb 14
Mon, Jan 28
Oct 5 2018
Looks good to me. Just one question, why didn't you use MIR as test file?
Jul 27 2018
Yes. I think that it make sense. IsCopyInstr() currently supports check target specific instructions, but with that extension it could be used to check more general instructions. The only thing that this extension needs to worry about is proper setting of source and destination operands, but I suppose that all of this instructions that are considered as IsCopy() have source as operand 1 and destination as operand 0.
Jul 12 2018
Thank you for review!
Jul 9 2018
renamed makeTransferDebugPair -> insertTransferDebugPair
renamed transfer -> process
removed unnecessary DILocation metadata from tests
Jul 2 2018
Jun 27 2018
One of my colleagues should commit this soon.
Jun 26 2018
Thank you for reviewing!
Jun 21 2018
I thought that comments were submitted along with patch.
Jun 20 2018
@aprantl do you have any more concerns or is this ready for commit?
Jun 13 2018
Jun 8 2018
Jun 7 2018
Updated patch to match TII isCopyInstr instruction.
Jun 5 2018
Updated isCopyInstr to take pointer to reference of MachineOperand.
Yes. I agree. It would look prettier with reference. But we can't construct default MachineOperand like "MachineOperand MO;" and pass it to this isCopyInstr. We could construct it like "MachineOperand MO = MachineInstr::CreateReg();" but that is unnecessary object construction. Better way would be without need for object construction. Is my reasoning correct or am I missing something?
Jun 1 2018
May 25 2018
May 23 2018
Updating patch to match latest trunk version.
May 21 2018
Updated just comment in ARMBaseInstrInfo.cpp
May 14 2018
A general pointer you might have missed. We already track copy like instructions through isRegSequenceLike, isExtractSubRegLike and so on. These are more complicated than just plain copies though (e.g., VMOVRRD should already be supported).
May 10 2018
@qcolombet Yes. It would be nice to have such interface but it would require a lot of additional work ( which would need to address all needed generic opcodes). This patch could be part of such work.
Apr 17 2018
Apr 13 2018
@kparzysz There are already instructions that have different bits set for different opcodes. But you have a point. In purpose of creating useful interface for TII the best way may be to use such bit isPossilbe[copy/move] to exclude non-copy-instructions and after exclusion return source and destination registers depending on opcode? Or just do it without MCInstDesc exclusion?
@sdardis What do you think about this?
Why can't you use that hook then? Make it available for all targets in TargetInstrInfo. I think that adding such bits to the instruction descriptor is a bad idea in general.
Added FIXME in ARMBaseInstrInfo::isCopyInstr
Untagged isMoveReg from VMOVRRD
Apr 12 2018
Removed isMoveReg from avx512_move_gpr
Apr 11 2018
[ARM] Consider VORRq as copy instruction when two inputs are the same register
Treat tMOVsr as isMoveReg Treat VMOVRRD as isMoveReg
Apr 10 2018
Apr 6 2018
Apr 3 2018
Splited patch in two revisions -> https://reviews.llvm.org/D45204
Apr 2 2018
Sure. I will do so. Do you think that it would be better to provide 3 different patches for X86/ARM/MIPS separately or should I post it all in one?
Mar 30 2018
Mar 27 2018
I've added test case for MIPS integer/float point values and tests for tracking integer values for X86 and ARM. Because it is hard to find a small real example I produced test cases by manually altering the machine IR but I'm not quite sure about producing test case for floating points for X86 and ARM. Basically what I've done is add 'isMoveReg = 1' to the instructions that are mentioned in TargetInstrInfo::copyPhysReg. Maybe someone else who is more familiar with ARM/X86 could assist or take over if everything else is fine?
Mar 20 2018
Updated test to recognize metadata id number.
Mar 19 2018
I've changed patch to perform locally now by restricting copy instructions recognition to ones that copy to callee saved registers.
I've also added test for mips64 that I've managed to find without making any changes to MIR. Also I've extended this functionality for recognizing some of X86 and ARM instructions (I've marked some of instructions in copyPhysReg TII method). I suppose that this could be extended even more by labeling other instructions as isMoveReg but I'm not familiar with other architectures.
Mar 13 2018
What "here" are you referring to?
Mar 12 2018
@aprantl > I've checked LiveDebugVariables pass and there is already such functionality but it performs only in blocks where DBG_VALUE is definded but copy instructions could occur in some further block. Maybe I should try to follow debuged value register location accros multiple blocks here and see whether it is copied to some other virtual register location?
Mar 5 2018
The first thought that came to my mind is: why not implement this functionality in DbgValueHistoryCalculator or DwarfDebug::buildLocationList(), or much earlier in LiveDebugVariables? I suppose that by doing it in LiveDebugValues there is a faint chance that we might be able to propagate a backup DBG_VALUE beyond basic block boundaries, but I'm not convinced that that is worth it.
Mar 2 2018
Feb 28 2018
Jan 15 2018
Jan 9 2018
Jan 8 2018
Jan 5 2018
Dec 29 2017
MBB.instr_end() changed to MBB.end()
Dec 20 2017
Dec 19 2017
Dec 18 2017
Please try it now.
Dec 15 2017
I wasn't able to produce simpler test example. I've deleted some of IR instructions from previous test. Deletion of any other instruction from IR would bypass the problem.
Dec 14 2017
Sep 21 2017
Sep 12 2017
Sep 8 2017
Aug 31 2017
Updating test case.
Aug 30 2017
Aug 29 2017
Updated test case
Aug 28 2017
val * (ValOther - ValInit) + ValInit:
If we are doing this expression, there should be an assertion in the code that ValInit < ValOther.
Aug 11 2017
Aug 10 2017
This patch implements new DIExpression :
Aug 1 2017
Sorry for spaming. First time using Phabricator. Uploaded wrong diff.
Changing test file from .c to .ll