search for: hasaddresstaken

...llvm-dev wrote: > > Dear Community, > > To improve current interprocedural register allocation (IPRA) , we have > planned to set callee saved registers to none for local functions, > currently I am doing it in following way: > > if (F->hasLocalLinkage() && !F->hasAddressTaken()) { > > > As an aside, you might want to analyze how many functions have both local > linkage and are not address taken. I recall that many functions returned > false for hasAddressTaken() because some direct calls casted the function > to a different function type before callin...

...v wrote: >> Dear Community, >> >> To improve current interprocedural register allocation (IPRA) , we have planned to set callee saved registers to none for local functions, currently I am doing it in following way: >> >> if (F->hasLocalLinkage() && !F->hasAddressTaken()) { > > As an aside, you might want to analyze how many functions have both local linkage and are not address taken. I recall that many functions returned false for hasAddressTaken() because some direct calls casted the function to a different function type before calling it. Such functio...

Dear Community, To improve current interprocedural register allocation (IPRA) , we have planned to set callee saved registers to none for local functions, currently I am doing it in following way: if (F->hasLocalLinkage() && !F->hasAddressTaken()) { DEBUG(dbgs() << "Function has LocalLinkage \n"); F->setCallingConv(CallingConv::GHC); } but we think threre should be clean and properway to do this perhaps like: if (F->hasLocalLinkage() && !F->hasAddressTaken()) { DEBUG(dbgs() << "Functio...

On 12/22/15 4:45 AM, Russell Wallace via llvm-dev wrote: > Oh, I just came across Function::hasAddressTaken. Maybe I can just use > that instead? You could conservatively assume that any function that has its address taken has a pointer to it that escapes into memory or external code. To make things a little more accurate, you could scan the uses of any function for which hasAddressTaken() retur...

PR43308 describes a case where StackProtector fails to protect against a fairly simple smash. This problem started after r363169, which removed StackProtector's own analysis function HasAddressTaken, and used CaptureTracking's PointerMayBeCaptured instead. The problem here is that "pointer is captured" and "pointer could be used to smash the stack" are not equivalent queries. The header of CaptureTracking.cpp says in part: A pointer value is captured if the function...

...registers and also we have thought that RegUsageInfoCalculator.cpp is having regmask that will make caller to save restore registers if both callee and caller is using any common register but this would require following change in RegUsageInfoCalculator.cpp : if (!F->hasLocalLinkage() || F->hasAddressTaken()) { const uint32_t *CallPreservedMask = TRI->getCallPreservedMask(MF, MF.getFunction()->getCallingConv()); // Set callee saved register as preserved. for (unsigned i = 0; i < RegMaskSize; ++i) RegMask[i] = RegMask[i] | CallPreservedMask[i]; } because R...

...rprocedural 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 RegMask due to CC with follwoing change in code: if (!F->hasLocalLinkage() || F->hasAddressTaken()) { co...

...; 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 RegMask due to CC with follwoing change in code: >> >> if (!...

...|| CC == CallingConv::GHC || CC == CallingConv::HiPE) > return true; > return false; > } > > Any other suggestions are always welcomed. Why aren’t checking for the presence of a tail call? — Mehdi > > and I am checking this condition along with hasLocalLinkage() and hasAddressTaken(). > > Due to this test-suite now has only 2 runtime failure where as before this there were around 43 due to local function related optimization. But of course by giving preference to tail call many opportunities to optimize IPRA is missed. > > The 2 existing failure are interesting...

...ization(Function *F) { CallingConv::ID CC = F->getCallingConv(); if (CC == CallingConv::Fast || CC == CallingConv::GHC || CC == CallingConv::HiPE) return true; return false; } Any other suggestions are always welcomed. and I am checking this condition along with hasLocalLinkage() and hasAddressTaken(). Due to this test-suite now has only 2 runtime failure where as before this there were around 43 due to local function related optimization. But of course by giving preference to tail call many opportunities to optimize IPRA is missed. The 2 existing failure are interesting and hard to debug, n...

...for the presence of a tail call? > Are you asking about if tail call optimization is enable or not? If not then above method is inspired from X86ISelLowering::canGuaranteeTCO(). -Vivek > > — > Mehdi > > > and I am checking this condition along with hasLocalLinkage() and > hasAddressTaken(). > > Due to this test-suite now has only 2 runtime failure where as before this > there were around 43 due to local function related optimization. But of > course by giving preference to tail call many opportunities to optimize > IPRA is missed. > > The 2 existing failure are...

...RA) 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 RegMask due to CC with follwoing change in code: > > if (!F->hasLocalLinkage() || F...

I need to track down all pointers anywhere in a module that could be pointing to functions (because some of the optimizations I want to do, require either identifying every use of a function, or conservatively identifying when such cannot be done). A starting point is to look at all the global variables: for (auto &G : M.globals()) for (auto &V : G.operands()) if (auto F =

...n } --- I have initially following correspondence: BB1 -> MBB10 (aka, BasicBlock 1 corresponds to MachineBasicBlock 10) After splitting MBB10 at the call instruction, we get : BB1 -> MBB10, MBB11 Because I need the address of MBB11, I found that I need to ensure that 'MBB11->hasAddressTaken()' returns true. Otherwise it can be optimized away. This can be done by: MBB11->setHasAddressTaken(); But this is not sufficient: an assertion failure in llvm::MMIAddrLabelMap::getAddrLabelSymbolToEmit(..) is triggered: 'BB->hasAddressTaken()' should also be set. The on...

...urning calls into tail calls during codegen? My assumption is that tail call is inferred on the IR, so you can inspect every *call site*. Mehdi > -Vivek >> >> — >> Mehdi >> >>> >>> and I am checking this condition along with hasLocalLinkage() and hasAddressTaken(). >>> >>> Due to this test-suite now has only 2 runtime failure where as before this there were around 43 due to local function related optimization. But of course by giving preference to tail call many opportunities to optimize IPRA is missed. >>> >>> The 2 e...

...any function that has its > address taken has a pointer to it that escapes into memory or > external code. > > > Right, that's what I'm doing to start with. > > To make things a little more accurate, you could scan the uses of > any function for which hasAddressTaken() returns true and see if > any of its uses escapes its function or escapes into memory or > external code. I believe hasAddressTaken() returns true if the > function is subjected to a cast instruction, and functions are > often casted if they are used in a call that us...

Nella citazione martedì 2 agosto 2011 22:01:13, Carlo Alberto Ferraris ha scritto: > My question is: > what is the best way to > express such relationships in LLVM IR ("best" in the sense of allowing > other optimizations to run effectively)? Bear in mind that in this > example N=2, but it may be way bigger than that. Just to clarify: I already figured out two ways to

Hi, I'm looking to see what's the best way to solve the fact that these two utils mostly do the same thing: 1. lib/Transforms/Utils/Local.cpp : MergeBasicBlockIntoOnlyPred 2. lib/Transforms/Utils/BasicBlockUtils.cpp : MergeBlockIntoPredecessor (+cc some of the folks who touched at least one of these either originally or recently) Brief overview: 1. MergeBasicBlockIntoOnlyPred 2.

Nella citazione martedì 2 agosto 2011 20:02:08, Michael Ilseman ha scritto: > I'm assuming that you're talking about a situation where this can't be > determined statically in the existing LLVM IR, but you know it's true > and want to put it in (e.g. you're the one generating LLVM IR). Correct. Or, more precisely, I'd like to investigate macro compression, i.e.