Displaying 5 results from an estimated 5 matches for "jcc_1".
2019 Apr 11
2
Question regarding X86::getCondFromBranch()
Hi,
I notice that the following recent addition
X86::CondCode X86::getCondFromBranch(const MachineInstr &MI) {
switch (MI.getOpcode()) {
default: return X86::COND_INVALID;
case X86::JCC_1:
return static_cast<X86::CondCode>(
MI.getOperand(MI.getDesc().getNumOperands() - 1).getImm());
}
}
returns an invalid condition for JCC_2 and JCC_4 conditional opcodes.
What is the suggested way to figure out the condition code for JCC_2 and JCC_4?
Should I just roll one up...
2020 Sep 09
2
[RFC] [DebugInfo] Using DW_OP_entry_value within LLVM IR
...ll to ext,
CALL64pcrel32 @ext, csr_64, [implicit defs]
; Loop increment:
renamable $rbx = nuw nsw ADD64ri8 killed renamable $rbx, 1,
debug-instr-number 1
DBG_INSTR_REF 1, 0, !16, !DIExpression(), debug-location !23
CMP64rr renamable $r14, renamable $rbx, implicit-def $eflags
JCC_1 %bb.2, 5, implicit $eflags
The label "debug-instr-number 1" on the ADD64ri8 identifies the ADD as
corresponding to the loop increment, and the DBG_PHI for $rbx as the
position where the loop PHI occurs. My key observation is that there
is a one-to-one relationship between LLVM-IR Values...
2019 Sep 27
2
What about multiple MachineMemOperands in one MI (BranchFolding/MachineInstr::mayAlias)?
...be interpreted when one MI has multiple MachineMemOperands?
(I've tried to find information but could not find any clear definition.)
For example BranchFolder may do things like this (also see https://godbolt.org/z/iphFH4):
# *** IR Dump Before Control Flow Optimizer ***:
bb.0.entry:
...
JCC_1 %bb.2, 5, implicit killed $eflags
JMP_1 %bb.1
bb.1.s1:
CALL64pcrel32 @bar, ... , implicit-def $rax
MOV16mr killed renamable $rax, 1, $noreg, 0, $noreg, renamable $bx :: (store 2 into %ir.r)
JMP_1 %bb.3
bb.2.s2:
CALL64pcrel32 @bar, ... , implicit-def $rax
MOV16mr killed renamable $rax, 1...
2020 Feb 28
5
A Propeller link (similar to a Thin Link as used by ThinLTO)?
I met with the Propeller team today (we work for the same company but it
was my first time meeting two members on the team:) ).
One thing I have been reassured:
* There is no general disassembly work. General
disassembly work would assuredly frighten off developers. (Inherently
unreliable, memory usage heavy and difficult to deal with CFI, debug
information, etc)
Minimal amount of plumbing work
2020 Sep 08
2
[RFC] [DebugInfo] Using DW_OP_entry_value within LLVM IR
Hi Djordje,
[Late reply as I was away, alas],
For the example in https://reviews.llvm.org/D85012 , I'm not sure that
just using an entry value is correct. The reason why the dbg.values
for arguments are set to undef is not because the value can't be
described, it's because deadargelim changes all the call sites to pass
in 'undef', which I believe makes the value unrecoverable