search for: determinecalleesav

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 from “*CallingConv.td” >>>; “build/lib/Target/XYX/” } ... SavedRegs.set(Reg); // to “add” a reg, EG...

..., and don’t find evidence where I would expect it for LLVM “downgrading” a function’s calling convention. IPRA is a project started ~ 2 months ago, there is nothing like that in 3.8 (neither downgrading, nor upgrading). — Mehdi PrologEpilogEmitter() { “CodeGen/” ... TFI->determineCalleeSaves() { “Target/XYZ/” TargetFrameLowering::determineCalleeSaves() { “CodeGen/” Return <<< some object derived from “*CallingConv.td” >>>; “build/lib/Target/XYX/” } ... SavedRegs.set(Reg); // to “add” a reg, EG...

...called across translation unit boundaries. The details about how this > contract is fulfilled are part of CodeGen IMO but do not need to be visible > at the IR level. > - The only thing we want to influence here is which registers are saved by > the callee. Changing TargetFrameLowering::determineCalleeSaves() is a good > place to achieve this without affecting unrelated things like parameter and > return value handling which would be part of the calling convention. > Hello Matthias, As per our discussion, the above trick will make sure that there is no callee saved registers and also we ha...

...be passed or any special rule for return value etc , it just required to set callee saved registers to be none. So what are the minimal things required to define such a CC? Other alternative that I have thought was to add new attribute for function and use it like following in TargetFrameLowering::determineCalleeSaves() // In Naked functions we aren't going to save any registers. if (MF.getFunction()->hasFnAttribute(Attribute::Naked)) return; Any suggestions / thoughts are welcomed ! Sincerely, Vivek -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lis...

Hello LLVM Community, To improve Interprocedural Register Allocation (IPRA) we are trying to force caller saved registers for local functions (which has likage type local). To achive it I have modified TargetFrameLowering::determineCalleeSaves() to return early for function which satisfies if (F->hasLocalLinkage() && !F->hasAddressTaken()) and also reflecting the fact that for local function there are no caller saved registers I am also changing RegUsageInfoCollector.cpp to not to mark regiseters as callee saved in RegMas...

...<vivekvpandya at gmail.com> wrote: > Hello LLVM Community, > > To improve Interprocedural Register Allocation (IPRA) we are trying to > force caller > saved registers for local functions (which has likage type local). To > achive it > I have modified TargetFrameLowering::determineCalleeSaves() to return > early for > function which satisfies if (F->hasLocalLinkage() && > !F->hasAddressTaken()) and > also reflecting the fact that for local function there are no caller saved > registers > I am also changing RegUsageInfoCollector.cpp to not to mark regise...

...; wrote: > >> Hello LLVM Community, >> >> To improve Interprocedural Register Allocation (IPRA) we are trying to >> force caller >> saved registers for local functions (which has likage type local). To >> achive it >> I have modified TargetFrameLowering::determineCalleeSaves() to return >> early for >> function which satisfies if (F->hasLocalLinkage() && >> !F->hasAddressTaken()) and >> also reflecting the fact that for local function there are no caller >> saved registers >> I am also changing RegUsageInfoCollector.c...

...lt;mailto:vivekvpandya at gmail.com>> wrote: > Hello LLVM Community, > > To improve Interprocedural Register Allocation (IPRA) we are trying to force caller > saved registers for local functions (which has likage type local). To achive it > I have modified TargetFrameLowering::determineCalleeSaves() to return early for > function which satisfies if (F->hasLocalLinkage() && !F->hasAddressTaken()) and > also reflecting the fact that for local function there are no caller saved registers > I am also changing RegUsageInfoCollector.cpp to not to mark regiseters as callee...

...ello LLVM Community, >>> >>> To improve Interprocedural Register Allocation (IPRA) we are trying to >>> force caller >>> saved registers for local functions (which has likage type local). To >>> achive it >>> I have modified TargetFrameLowering::determineCalleeSaves() to return >>> early for >>> function which satisfies if (F->hasLocalLinkage() && >>> !F->hasAddressTaken()) and >>> also reflecting the fact that for local function there are no caller >>> saved registers >>> I am also changing...

...;>>> >>>> To improve Interprocedural Register Allocation (IPRA) we are trying to >>>> force caller >>>> saved registers for local functions (which has likage type local). To >>>> achive it >>>> I have modified TargetFrameLowering::determineCalleeSaves() to return >>>> early for >>>> function which satisfies if (F->hasLocalLinkage() && >>>> !F->hasAddressTaken()) and >>>> also reflecting the fact that for local function there are no caller >>>> saved registers >>&gt...

...------- In the LLVM backend we can then use the module flags to add any (valid) specified global registers to the reserved reg list (getReservedRegs). In addition, to satisfy the second use-case*, we use the flags to remove any (valid) global registers from the list of callee registers to be saved (determineCalleeSaves). This shouldn't have any negative impact on a register that is already reserved for use. GCC seems to exhibit similar behaviour: "If the register is a call-saved register, call ABI is affected: the register will not be restored in function epilogue sequences after the variable has...

...pecial rule for return value etc , it just required to set callee saved registers to be none. So what are the minimal things required to define such a CC? >> >> Other alternative that I have thought was to add new attribute for function and use it like following in TargetFrameLowering::determineCalleeSaves() >> >> // In Naked functions we aren't going to save any registers. >> if (MF.getFunction()->hasFnAttribute(Attribute::Naked)) >> return; >> >> Any suggestions / thoughts are welcomed ! > > My humble opinion is that you should avoid hack...

...t;>>>>> >>>>>> To improve Interprocedural Register Allocation (IPRA) we are trying to force caller >>>>>> saved registers for local functions (which has likage type local). To achive it >>>>>> I have modified TargetFrameLowering::determineCalleeSaves() to return early for >>>>>> function which satisfies if (F->hasLocalLinkage() && !F->hasAddressTaken()) and >>>>>> also reflecting the fact that for local function there are no caller saved registers >>>>>> I am also changing Re...

...On 12/21/18 8:05 PM, Friedman, Eli via llvm-dev wrote: > As a side-note, you might want to check that prologue/epilogue emission won't emit a PUSH/POP that refers to a register reserved this way; we sometimes add an "extra" register to align the stack. Yes, you are right. Checking determineCalleeSaves(), we see that it maintains a number of free Register pools, UnspilledCS1GPRs, UnspilledCS2GPRs and AvailableRegs, which are used to find Registers that can be used for the extra callee saves you mentioned. There probably are more like this. Thanks for pointing that out. We will investigate and e...

Mehdi, I am looking for an understanding of 1) IPRA in general, 2) IPRA in LLVM. Whether I want to use LTO or not is a separate issue. 1) I currently believe it is a true statement that: If all external functions are known to not call back into the “whole-program” Being compiled, then IPRA is free to do anything at all to the functions being