search for: haslocallinkag

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()) {...

...at there is no callee saved 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] | CallPres...

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

...er 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 fol...

...== CallingConv::Fast || 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 f...

...igibleForTailCallOptimization(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 interesti...

...; > Why aren’t checking 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. > &gt...

.../16 9:39 AM, vivek pandya via 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...

...e 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 RegMask due to CC with follwoing change in code: &...

...On 6/20/16 9:39 AM, vivek pandya via 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...

>> Agreed. If ld64 can drop support for .o produced by the old gcc that >> would be awesome. Failing that, what is really needed is > Because of static archives, the linker has to support old .o files for quite a while. I also don’t know when clang starting getting this right. r123585 (Jan 16 17:19:34 2011) I think. > Also, this seems like linker complexity for a very

It seems that fast-isel for intel does not handle strlen. It's a general problem in fast-isel . ~/llvmw/build/Deb~/llvmw/build/Debug+Asserts/bin/clang -O0 -mllvm -fast-isel-verbose -mllvm -fast-isel strlen1.c strlen1.c:12:3: warning: implicitly declaring library function 'printf' with type 'int (const char *, ...)' printf("%i\n", len); ^

...CO(). > Are we turning 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. >>&gt...

Hello. I'm posting this question here, because there seem to be no LLD-specific mailing list. Sorry in advance if this is wrong one. I compile two C source with following command: clang -flto -o %name.bc %name.c LLVM is augmented with my custom pass, which amongst other things create a global with appending linkage: @myvar = appending constant [1 x [1 x i8]*] ... I also have another pass

...Sel phase. > So I moved this optimization at CodeGenPrepare which happens before ISel. > Now I am not getting the above bug. But the result of this optimization is > not good ( I mean no positive change in generated code) also due to the > condition F.doesNotAccessMemory() && !F.hasLocalLinkage() very few of cold > functions are really getting optimized. > > One more thing how to test test-suite with PGO and also use generated > profiles in next run. I mean any easy way? > I just want to be sure if any more kind of case is not covered. > > -Vivek > >> - Mat...

How can I check if an operand is a static variable in the IR? I've read that their linkage type should be marked as "internal" in the .s file, but I can't find a way to test if an Instruction has static variables as operands. Can you help me? Thank you in advance, Niko

...t; > Hello all, > > Adding MatzeB this may be interesting for him. > > I have tried out following way to save most of the registers for cold functions, in RegisterUsagePropagation.cpp > > if (PSI->isColdFunction(F) && F->doesNotAccessMemory() && !F->hasLocalLinkage()) { > dbgs() << "Cold Function : " << F->getName() << "\n"; > F->setCallingConv(CallingConv::CXX_FAST_TLS); > } > > previously I was using CallingConv::PreserveMost but it also saves RAX and that generated bug for functions...

Hi, When I’m compiling a code with –fvisibility=hidden –fPIC for ARM, I find that LLVM generates less optimized code than GCC. For example: test.cpp: void init(void *); int g0[100]; int g1[100]; int g2[100]; void foo() { init(&g0); init(&g1); init(&g2); } Clang will emit 1 GOT entry for each GV and 2 instructions to get the address: ldr

On Tue, Apr 4, 2017 at 12:36 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > On 2017-Apr-04, at 12:12, Peter Collingbourne <peter at pcc.me.uk> wrote: > > On Mon, Apr 3, 2017 at 8:13 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Apr 3, 2017, at 7:08 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: >>

----- Original Message ----- > From: "vivek pandya" <vivekvpandya at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Quentin Colombet" > <qcolombet at apple.com>, "Mehdi Amini" <mehdi.amini at apple.com> > Sent: Friday, July 29, 2016 5:02:44 AM >