Displaying 9 results from an estimated 9 matches for "x86instrbuild".
Did you mean:
x86instrbuilder
2004 Aug 29
3
[LLVMdev] Optimization opportunity
...to apply it. Continuing improvements in the code
> generator should eventually make this kind of thing fall out
> automatically, but for now they must be implemented manually.
>
> -Chris
I succumbed to temptation and made the improvement. Diffs are attached
for X86ISelSimple.cpp and X86InstrBuilder.h.
I determined that the reason two instructions are generated in the first
place, instead of being folded immediately into one, is because locals
do not have a physical offset assigned at that time. There is a
peephole optimization pass after the stack frame is finalized, but the
problem with...
2005 Aug 11
1
[LLVMdev] Define an instruction with many operands
...9;s the difference between these two implementations to
define the instruction in TableGen *.td file?
(1) Similar to what has been done to complex X86 addressing mode. A
single 32-bit immediate (i32) encodes how to add many MachineOperands
to the MachineInstr object (With the help of functions in
X86InstrBuilder.h).
// similar to X86MemOperand in X86InstrInfo.td !!
class ManyOperands : Operand<i32> {
let NumMIOperands = 100; // a very large number
let PrintMethod = "printManyOperands";
}
def MO : ManyOperands;
def FOOBAR: Instruction<(ops MO:$operands), "foobar {$operands}&q...
2004 Oct 19
2
[LLVMdev] Question about MachineFunction Pass
...remove MachineFunctions from the current Module.
4.. Add or remove global variables from the current Module.
5.. Maintain state across invocations of runOnMachineFunction (including global data)
It seems I cannot insert some instructions, right?
For MachineInstr.h and MachineInstrBuilder.h and X86InstrBuilder.h, I am just wondering if we can construct some X86 assemble instruction? if so, can we insert the X86 assemble instruction to bytecode( bytecode is IR code which should be conflicted with X86 asm) if I used runOnMachineFunction pass ?
2004 Aug 27
0
[LLVMdev] Optimization opportunity
On Thu, 26 Aug 2004, Jeff Cohen wrote:
> There seems to be a disadvantage to the approach of allocating all
> locals on the stack using alloca. Consider the following code:
There is nothing intrinsic in LLVM that prevents this from happening, we
just have not yet implemented 'stack packing'.
> We have two arrays, b and c, only one of which can exist at any given
> time.
2004 Aug 27
2
[LLVMdev] Optimization opportunity
There seems to be a disadvantage to the approach of allocating all
locals on the stack using alloca. Consider the following code:
extern void func(int*);
extern int xyz();
void abc()
{
int a = xyz();
int i;
{
int b[10];
for (i = 0; i < 10; i++) b[i] = xyz();
func(b);
}
{
int c[10];
for (i = 0; i < 10; i++) c[i] = xyz();
func(c);
}
func(&a);
}
We have two arrays,
2004 Oct 19
0
[LLVMdev] Question about MachineFunction Pass
...nt to
do.
> For MachineFunction pass, the doc says it is not allowed to do any of the following:
MachineFunctionPass's are even more restricted than FunctionPass's.
> It seems I cannot insert some instructions, right?
Correct.
> For MachineInstr.h and MachineInstrBuilder.h and X86InstrBuilder.h, I am
> just wondering if we can construct some X86 assemble instruction? if so,
Yes.
> can we insert the X86 assemble instruction to bytecode( bytecode is IR
> code which should be conflicted with X86 asm) if I used
> runOnMachineFunction pass ?
No you can't do this yet, and...
2004 Aug 29
0
[LLVMdev] Optimization opportunity
...ts in the code
> > generator should eventually make this kind of thing fall out
> > automatically, but for now they must be implemented manually.
> >
> > -Chris
>
> I succumbed to temptation and made the improvement. Diffs are attached
> for X86ISelSimple.cpp and X86InstrBuilder.h.
>
> I determined that the reason two instructions are generated in the first
> place, instead of being folded immediately into one, is because locals
> do not have a physical offset assigned at that time. There is a
> peephole optimization pass after the stack frame is finaliz...
2007 Jul 24
1
[LLVMdev] alias information on machine instructions
Dan Gohman wrote:
> I tried out your patch on x86 and it didn't appear to need any special changes.
it might be needed to look at the addressing modes of a load/store to
get the right offset. but i think it should work, if the lowering does
not rewrite loads/stores into custom DAG nodes.
> For the [??], it looks like the IsFrameIndex isn't getting set for the first
> instruction
2004 Dec 03
2
[LLVMdev] [Fwd: Updated LLVM Visual Studio project files]
...t; Filter="h;hpp;hxx;hm;inl;inc;xsd"
> UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}">
> <File
> RelativePath="..\..\lib\Target\X86\X86.h">
> </File>
> <File
> RelativePath="..\..\lib\Target\X86\X86InstrBuilder.h">
> </File>
> <File
> RelativePath="..\..\lib\Target\X86\X86InstrInfo.h">
> </File>
> <File
> RelativePath="..\..\lib\Target\X86\X86JITInfo.h">
> </File>
> <File
> RelativePath=...