Displaying 20 results from an estimated 500 matches similar to: "[LLVMdev] Patch/Question: calculateFrameObjectOffsets"
2004 Jun 09
2
[LLVMdev] X86 Frame info question
The X86 backend has this code:
X86TargetMachine::X86TargetMachine(const Module &M, IntrinsicLowering *IL)
: ....
FrameInfo(TargetFrameInfo::StackGrowsDown, 8/*16 for SSE*/, 4),
That is, it uses "4" as local area offset. Based on prior discussion this
should mean that the local area starts and address ESP+4. Is this really
true? On X86 stack grows down, so
2006 Oct 06
2
[LLVMdev] should PEI::calculateFrameObjectOffsets align the stack?
In ARM the stack should be 8 bytes aligned during function calls. A
function that has at least one function call then has a stack size of
8 bytes. PEI::calculateFrameObjectOffsets corretly computes this
correctly.
The problem is that the alignment is computed before adding space for
the call frame size. This is done in emitProlog. Currently the ARM
backend has a bug in that it doesn't align
2006 Oct 08
1
[LLVMdev] should PEI::calculateFrameObjectOffsets align the stack?
> That is irrelevant. The PEI code needs to know how much stack space is
> required for each call to allocate and align the stack frame properly. It
> gets this info from the ADJCALLSTACK instructions.
I see. Looking at PEI::calculateCalleeSavedRegisters shows that the
ADJCALLSTACK instructions is used to set up MaxCallFrameSize. Adding
debug prints also show that in the example code
2006 Oct 06
0
[LLVMdev] should PEI::calculateFrameObjectOffsets align the stack?
On Fri, 6 Oct 2006, [UTF-8] Rafael Esp?ndola wrote:
> In ARM the stack should be 8 bytes aligned during function calls. A
> function that has at least one function call then has a stack size of
> 8 bytes. PEI::calculateFrameObjectOffsets corretly computes this
> correctly.
>
> The problem is that the alignment is computed before adding space for
> the call frame size. This is
2006 Oct 07
0
[LLVMdev] should PEI::calculateFrameObjectOffsets align the stack?
On Sat, 7 Oct 2006, [UTF-8] Rafael Esp?ndola wrote:
>> This sounds like the ADJCALLSTACK DOWN/UP 'instructions' around the call
>> aren't set right, or you have declared a SP offset. It doesn't look like
>> the ARM backend does this, so this is probably the problem.
> The ARM backend currently doesn't use a frame pointer. It uses the
> same technique
2013 May 31
0
[LLVMdev] Customizing PEI::calculateFrameObjectOffsets()
I would like a customized version of the function
PEI::calculateFrameObjectOffsets() in PrologEpilogInserter.cpp.
What is the clean way to do this?
2006 Oct 07
2
[LLVMdev] should PEI::calculateFrameObjectOffsets align the stack?
> This sounds like the ADJCALLSTACK DOWN/UP 'instructions' around the call
> aren't set right, or you have declared a SP offset. It doesn't look like
> the ARM backend does this, so this is probably the problem.
The ARM backend currently doesn't use a frame pointer. It uses the
same technique of the PPC backend to avoid add/subs around calls. In
the PPC backend we
2013 Sep 25
2
[LLVMdev] Register scavenger and SP/FP adjustments
Hi All,
I'm dealing with a problem where the spill/restore instructions inserted
during scavenging span an adjustment of the SP/FP register. The result
is that despite the base register (SP/FP) being changed between the
spill and the restore, both store and load use the same immediate offset.
I see code in the PEI (replaceFrameIndices) that is supposed to track
the SP/FP adjustment:
2013 Sep 26
0
[LLVMdev] Register scavenger and SP/FP adjustments
CallFrameSetupOpcode is a pseudo opcode like X86::ADJCALLSTACKDOWN64. That means when the code is expected to be called before the pseudo instructions are eliminated. I don't know why it's not the case for you. A quick look at PEI code indicates the pseudo's should not have been removed at the time when replaceFrameIndices are run.
Evan
On Sep 25, 2013, at 8:57 AM, Krzysztof
2013 Sep 26
2
[LLVMdev] Register scavenger and SP/FP adjustments
Consider this example:
--- ex.ll ---
declare void @bar()
; Function Attrs: nounwind optsize
define void @main() {
entry:
%hin = alloca [256 x i32], align 4
%xin = alloca [256 x i32], align 4
call void @bar()
ret void
}
-------------
Freshly built llc:
llc -O2 -march=x86 < ex.ll -print-before-all
# *** IR Dump Before Prologue/Epilogue Insertion & Frame Finalization ***:
#
2013 Sep 26
0
[LLVMdev] Register scavenger and SP/FP adjustments
The code has changed a lot over the years. Looks like at some point of time the assumption was broken. calculateCallsInformation() may have eliminated the pseudo set up instructions already.
// If call frames are not being included as part of the stack frame, and
2013 Sep 26
1
[LLVMdev] Register scavenger and SP/FP adjustments
Thanks, I'll look into that. Still, the case where the function does
not call anything remains---in such a situation there are no
ADJCALLSTACK pseudos, so regardless of what that function you pointed at
does, there won't be any target-independent information about the SP
adjustment by the time the frame index elimination runs.
Would it make sense to have ADJCALLSTACK pseudos every
2016 Jul 13
2
IPRA, interprocedural register allocation, question
Mehdi,
I am perusing the 3.8 trunk sources, and don’t find evidence where I
would expect it for LLVM “downgrading” a function’s calling convention.
PrologEpilogEmitter() { “CodeGen/”
...
TFI->determineCalleeSaves() { “Target/XYZ/”
TargetFrameLowering::determineCalleeSaves() { “CodeGen/”
Return <<< some object derived
2004 Jun 09
0
[LLVMdev] X86 Frame info question
On Wed, 9 Jun 2004, Vladimir Prus wrote:
>
> The X86 backend has this code:
>
> X86TargetMachine::X86TargetMachine(const Module &M, IntrinsicLowering *IL)
> : ....
> FrameInfo(TargetFrameInfo::StackGrowsDown, 8/*16 for SSE*/, 4),
>
> That is, it uses "4" as local area offset. Based on prior discussion this
> should mean that the local
2010 Apr 11
3
[LLVMdev] Proposal: stack/context switching within a thread
Kenneth Uildriks <kennethuil at gmail.com> wrote:
> As I see it, the context switching mechanism itself needs to know
> where to point the stack register when switching. The C routines take
> an initial stack pointer when creating the context, and keep track of
> it from there. If we don't actually need to interoperate with
> contexts created from the C routines, we have
2016 Jul 13
2
IPRA, interprocedural register allocation, question
Mehdi,
I’m seeing lots of “upgrading” logic,
If (UseIPRA)
createPass(new DummyCGSCCPass);
if (UseIPRA)
addPass(createRegUsageInfoPropPass());
if (UseIPRA)
addPass(createRegUsageInfoCollector());
???
--Peter.
From: mehdi.amini at
2004 Jul 01
1
[LLVMdev] Stack alignment problem
Hello,
it seems the Prolog/Epilog insertion does not correctly align stack for me.
Consider the PEI::calculateFrameObjectOffsets method. It only aligns the
stack if
FFI->hasCalls()
is true. The only place where
MachineFrameInfo::setHasCalls
is invoked is
PEI::saveCallerSavedRegisters
and the value 'true' is only passed when there are instructions with opcodes
equal
2012 Oct 22
0
[LLVMdev] register scavenger
I have a question about register scavenger.
I am considering using register scavenger for MIPS to free up register AT
which is currently reserved to load large immediates.
All targets which currently use register scavenger to search for a scratch
register (ARM, CellSPU, PowerPC and XCore)
override function processFunctionBeforeCalleeSavedScan and call
RegisterScavenger::setScavengingFrameIndex
2012 Apr 07
5
FFI and msvcrt
Hi,
I''ve been using FFI with a Ruby 1.9.3 built with MSVC++ and it''s been
working well. One thing I''ve run into though is this:
ffi_lib :msvcrt
But that''s not the runtime I want. But I don''t want to hard code the
runtime name either. I realize I could parse it out of RbConfig, but I
was hoping for something nicer.
Is there a way we could create an
2005 Jul 11
2
[LLVMdev] X86AsmPrinter + MASM and NASM backends
>>> You shouldn't have to add new classes to the .td file, just modify
>>> printOp for your asmprinters.
>>
>> I dont think printOp is virtual and therefore cannot be overriden ?
>
> Why does it need to be virtual? No 'intel' printers want % signs.
The GAS intel code generator generates percents, look at the X86InstrInfo.td
file it is full of