Displaying 20 results from an estimated 5000 matches similar to: "[LLVMdev] X86: copyConstantToRegister"
2004 Jun 07
0
[LLVMdev] X86: copyConstantToRegister
On Mon, 7 Jun 2004, Vladimir Prus wrote:
>
> Hello,
> looking at X86 codegen, I see this:
>
> void ISel::copyConstantToRegister(MachineBasicBlock *MBB,
> MachineBasicBlock::iterator IP,
> Constant *C, unsigned R) {
> if (ConstantExpr *CE = dyn_cast<ConstantExpr>(C)) {
> .....
> case
2004 Jun 08
1
[LLVMdev] X86: copyConstantToRegister
Chris Lattner wrote:
> > I'm not sure I understand this logic. If we have "1 + 2" as constant
> > expression, then why emit the code to perform addition? It should be
> > possible to just fold the expression and copy immediate "3" into a
> > register.
> >
> > I must be missing something, but what?
>
> LLVM constant expressions are
2004 Jun 18
1
[LLVMdev] Getelementptr woes
Chris Lattner wrote:
> > So I wonder if I can away by writing two passes which work on LLVM level.
> > The first pass would extract all ConstantExpr* operands from instructions
> > and move them into separate instructions. E.g. the example above would
> > become:
> >
> > %tmp.1 = sbyte* getelementptr ([11 x sbyte]* %.str_1, ..........
> > %tmp.0.i =
2004 Jun 17
0
[LLVMdev] Getelementptr woes
On Thu, 17 Jun 2004, Vladimir Prus wrote:
> I'm having problems with the following LLVM instruction
>
> %tmp.0.i = call int (sbyte*, ...)*
> %printf( sbyte* getelementptr ([11 x sbyte]* %.str_1, long 0, ......
>
> The first argument in function call,
>
> sbyte* getelementptr ([11 x sbyte]* %.str_1.....
>
> appears to be ConstantExpression*, and my
2004 Jun 17
2
[LLVMdev] Getelementptr woes
Hello,
I'm having problems with the following LLVM instruction
%tmp.0.i = call int (sbyte*, ...)*
%printf( sbyte* getelementptr ([11 x sbyte]* %.str_1, long 0, ......
The first argument in function call,
sbyte* getelementptr ([11 x sbyte]* %.str_1.....
appears to be ConstantExpression*, and my backend does not support
ConstantExpression yet.
I probable can implement
2008 Apr 15
4
[LLVMdev] Being able to know the jitted code-size before emitting
OK, here's a new patch that adds the infrastructure and the
implementation for X86, ARM and PPC of GetInstSize and GetFunctionSize.
Both functions are virtual functions defined in TargetInstrInfo.h.
For X86, I moved some commodity functions from X86CodeEmitter to
X86InstrInfo.
What do you think?
Nicolas
Evan Cheng wrote:
>
> I think both of these belong to TargetInstrInfo. And
2019 May 10
2
[Pipeliner] MachinePipeliner TargetInstrInfo hooks need more information?
Hello,
I'm working on integrating the MachinePipeliner.cpp pass into our VLIW
backend, and so far we've managed to get it working with some nice
speedups.
Unlike Hexagon however, our backend doesn't generate hardware loop
instructions and so all our loops are a combination of induction
variables, comparisons and branches. So when it came to implementing
reduceLoopCount for our
2008 Jan 27
2
[LLVMdev] BreakCriticalMachineEdge.h
Hi LLVMers,
what is the status of breaking critical edges in machine functions? I
just compiled the top of the LLVM tree, and I found
llvm/CodeGen/BreakCriticalMachineEdge.h. But this file seems not to be
up-to-date with the other classes in the top of the tree. For instance, it
calls isTerminatorInstr on llvm::TargetInstrInfo, but this method is no
longer there.
If I want to break
2007 Aug 19
1
[LLVMdev] MBB Critical edges
Hi,
This pass is similar to the one in BreakCriticalEdges.cpp, but it works
for MachineFunction's, instead of Functions. The existence of critical
edges complicates many optimizations. When doing register allocation, you
don't necessarily have to remove critical edges (you can use conventional
SSA-form, for instance. See "Translating Out of Static Single Assignment
Form. SAS
2008 Jan 27
0
[LLVMdev] BreakCriticalMachineEdge.h
Fernando,
The code there should be more or less functional, though it's not
currently used by anything. Eventually it should probably be moved to
a method on MachineBasicBlock.
The API breakage you're seeing is because some methods moved around.
Feel free to fix it. :-)
--Owen
On Jan 26, 2008, at 6:31 PM, Fernando Magno Quintao Pereira wrote:
>
> Hi LLVMers,
>
>
2009 Jul 17
2
[LLVMdev] Bug in LiveIntervals? Please Examine
In LiveIntervals::processImplicitDefs() we have this:
for (MachineRegisterInfo::use_iterator UI = mri_->use_begin(Reg),
UE = mri_->use_end(); UI != UE; ) {
MachineOperand &RMO = UI.getOperand();
MachineInstr *RMI = &*UI;
++UI;
MachineBasicBlock *RMBB = RMI->getParent();
if (RMBB == MBB)
continue;
const
2010 Oct 20
1
[LLVMdev] MachineBasicBlock insertion
Hi all,
I am really stumped on a problem for long. I could not figure out why.
That is why i am here. OK, here is the problem:
I tried to insert a MachineBasicBlock into a function. Here is the code
snippet:
// insert a machine basic block with the error_label into MF and before I
// Pred is the predecessor of the block to be inserted
// the new basic block is inserted right before I
void
2020 Nov 12
2
LLVM X86 MachineBasicBlock inserting push and pop instructions causes segmentation fault
Hello,
I am working on a project where I need to insert some logic before each
machine basic block.
In particular, it involves setting some global variables and calling a
function. I'm able to add the instructions and verify they get added, but
when the compiled program runs, it stops with a segfault.
For brevity, I'm not sharing the whole code here but basically I have a X86
2014 Dec 08
2
[LLVMdev] Virtual register problem in X86 backend
Hi,
I'm having trouble using virtual register in the X86 backend.
I implemented a new intrinsic and I use a custom inserter. The goal of
the intrinsic is to set the content of the stack to zero at the end of
each function.
Here is my code:
MachineBasicBlock *
X86TargetLowering::EmitBURNSTACKWithCustomInserter(
MachineInstr *MI,
MachineBasicBlock
2007 Aug 17
0
[LLVMdev] MBB Critical edges
Sorry about the tardiness of my reply. My mail client has playing
tricks with me. :-)
I am assuming the issue has nothing to do the branch to jumptable
instructions but rather the MachineJumpTableInfo associated with every
MachineFunction? If so, please take a look at BranchFoldiing.cpp for
an example.
Evan
On Aug 10, 2007, at 12:30 PM, Fernando Magno Quintao Pereira wrote:
>
>
2007 Aug 10
2
[LLVMdev] MBB Critical edges
Hi all,
I have a pass to break critical edges of Machine Basic Blocks, but I
just discovered a bug (when compiling code for x86). The problem is 'jumpl
*%reg'. I don't know how to update the jump table for this type of
instruction. The code that I had (see below) does not update the jump
table, and the actual branch keeps jumping to the old basic block, instead
of the new.
2007 Aug 17
2
[LLVMdev] MBB Critical edges
Thanks, Evan.
Actually I've solved my problem with some hints from Dale and Anton.
At least I think I've solved it. I had to add one method to
TargetInstrInfo to tell me when an instruction is an indirect jump -
TargetInstrInfo::tii.isIndirectJump(opcode). When that is the case, I
update the jump table using:
// Change jumps to go to the new basic block:
2014 Jul 26
2
[LLVMdev] Finding previous emitted instruction
Hi All,
For various obscure reasons I'd like to detect the condition when X86 CALL
instruction immediately precedes a function epilogue in the final emitted
code, and insert a NOP between them if that happens.
My initial attempt at it looked like this:
MachineBasicBlock& MBB;
MachineBasicBlock::iterator MBBI; <-- points to where the epilogue would
be inserted
if (MBBI != MBB.begin()
2006 Jul 05
0
[LLVMdev] Critical edges
> If you don't want critical edges in the machine code CFG, you're going to
> have to write a machine code CFG critical edge splitting pass: LLVM
> doesn't currently have one.
>
> -Chris
Hey guys,
I've coded a pass to break the critical edges of the machine
control flow graph. The program works fine, but I am sure it is not
the right way of implementing it.
2009 Jul 17
0
[LLVMdev] Bug in LiveIntervals? Please Examine
On Jul 17, 2009, at 7:57 AM, David Greene wrote:
> In LiveIntervals::processImplicitDefs() we have this:
>
> for (MachineRegisterInfo::use_iterator UI = mri_->use_begin(Reg),
> UE = mri_->use_end(); UI != UE; ) {
> MachineOperand &RMO = UI.getOperand();
> MachineInstr *RMI = &*UI;
> ++UI;
> MachineBasicBlock *RMBB