similar to: Fixing some StackProtector issues

Hi there lowering experts, Can the llvm.mem* intrinsics ever turn into a library call? Or do they invariably turn into inline code? This comes up because there was a patch to StackProtector to use CaptureTracking instead of a home-grown analysis, which changes the treatment of calls to intrinsics. (The old code treated them as normal calls, the new code decides intrinsics can never capture.)

On Tue, Jun 21, 2016 at 8:58 PM, John Criswell <jtcriswel at gmail.com> wrote: > On 6/20/16 11:29 PM, Mehdi Amini wrote: > > > On Jun 20, 2016, at 11:12 AM, John Criswell via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > On 6/20/16 9:39 AM, vivek pandya via llvm-dev wrote: > > Dear Community, > > To improve current interprocedural register

> On Jun 20, 2016, at 11:12 AM, John Criswell via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > 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:

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

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

Some background: We have an issue with in loop values being correctly marked uniform but the out of loop uses can be non-uniform. Currently the out of loop users are not marked as divergent because the in loop value is uniform inside the loop. We have gotten around this problem for the moment by applying LCSSA which inserts a PHI in the loop exit for the in loop uniform value that allows the

Any comments at all on this? Chandler perhaps? I've since dug a bit further, and it seems like the template-based solution wouldn't work anyway because DLL loading on Windows can't do the required commoning. So the general approach taken in https://reviews.llvm.org/D62802 seems to be the only technically viable path forward, though it would still be good to get an outside look at the

On Tue, Jun 21, 2016 at 12:31 AM, Matthias Braun <matze at braunis.de> wrote: > I just discussed this with vivek on IRC (and I think we agreed on this): > > Let me first state the motivation clearly to ease later discussions: > As far as the motivation for this change goes: Changing the calling > convention allows us to choose whether a register is saved by the callee or >

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

According to this http://llvm.org/docs/CodeGenerator.html#tail-call-section, it seems that adding a new CC for the purpose of local function optimization seems a good idea because tail call optimization only takes place when both caller and callee have fastcc or GHC or HiPE calling convention. -Vivek On Sun, Jun 26, 2016 at 1:26 AM, vivek pandya <vivekvpandya at gmail.com> wrote: >

> On Jun 27, 2016, at 12:25 PM, vivek pandya <vivekvpandya at gmail.com> wrote: > > Hello , > > To solve this bug locally I have given preference to tail call optimization over local function related optimization in IPRA. I have added following method to achieve this: > > bool isEligibleForTailCallOptimization(Function *F) { > CallingConv::ID CC =

Hello , To solve this bug locally I have given preference to tail call optimization over local function related optimization in IPRA. I have added following method to achieve this: bool isEligibleForTailCallOptimization(Function *F) { CallingConv::ID CC = F->getCallingConv(); if (CC == CallingConv::Fast || CC == CallingConv::GHC || CC == CallingConv::HiPE) return true; return false;

On Tue, Jun 28, 2016 at 8:11 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Jun 27, 2016, at 12:25 PM, vivek pandya <vivekvpandya at gmail.com> wrote: > > Hello , > > To solve this bug locally I have given preference to tail call > optimization over local function related optimization in IPRA. I have added > following method to achieve this: > >

I'm still working on SSP support in LLVM. We have code that is in an IR pass StackProtector, SelectionDAG, FastISel, and some MachineFunction passes. Even in SelectiondDAG we have different code paths. I wonder if we can at least have only two code paths, one for SelectionDAG and the other for FastISel. IR pass may generate two forms of IR: 1) Almost pure IR, which contains only

On Sat, Jun 25, 2016 at 11:03 PM, vivek pandya <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 >

Hi all, I am master student in Edinburgh, UK. I am doing my MSc project with LLVM compiler and I have to modify LLVM to implement the StackGuard with a XOR random Canary. However, I am not familiar with LLVM. My problem is that I want to XOR the random canary word with the return address which are both 32 bits. I found a method called SimplifyXorInst(Value *, Value *, const TargetData

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 =

Hi all, I think that I came somewhat closer to a solution for splitting a MachineBasicBlock for a PSEUDO_CALL_R instruction and having a label to the new MBB: For following piece of code: --- typedef int callme_t(int a, int b); callme_t* c01; int foo(int a, int b) { return c01(a,b); // MachineBasicBlock will be split at call instruction } --- I have initially following correspondence: BB1

Sent from my iPhone > On Jun 28, 2016, at 12:53 PM, vivek pandya <vivekvpandya at gmail.com> wrote: > > > >> On Tue, Jun 28, 2016 at 8:11 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: >> >>> On Jun 27, 2016, at 12:25 PM, vivek pandya <vivekvpandya at gmail.com> wrote: >>> >>> Hello , >>> >>> To solve

On Dec 27, 2008, at 2:28 PM, Nicolas Geoffray wrote: > Hi everyone, > > As a front-end developer, I'd like to add a language-specific > information at a fixed location of each stack frame. The reason is > that > I want to retrieve this information when dynamically walking the > stack. > > For example, X86 has the following stack layout for a function with >