similar to: Missing attribute inference cases

Maybe we could list some of these as a GSoC project? Seems like a self-contained task that can be simple as desired and as hard as the student wants it to be. Nuno -----Original Message----- From: Philip Reames via llvm-dev Sent: Friday, February 16, 2018 6:48 PM To: llvm-dev Subject: Re: [llvm-dev] Missing attribute inference cases On 02/16/2018 10:29 AM, Philip Reames via llvm-dev wrote:

Sure, but is anyone willing to mentor?  I don't have time.  I can advise, but only infrequently. Philip On 02/16/2018 03:47 PM, Davide Italiano wrote: > Yes, I agree with you this sounds like a great GSoC. > > On Fri, Feb 16, 2018 at 3:42 PM, Nuno Lopes via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Maybe we could list some of these as a GSoC project?

On 02/16/2018 10:29 AM, Philip Reames via llvm-dev wrote: > > This email is just to summarize a bit of digging I did last night into > our attribute inference.  Unfortunately, I'm not going to have time to > implement any of the gaps I noticed, but I figured someone else out > there might be interested. > > *Missing Attributes* > > argmemonly - influences AA,

Yes, I agree with you this sounds like a great GSoC. On Fri, Feb 16, 2018 at 3:42 PM, Nuno Lopes via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Maybe we could list some of these as a GSoC project? > Seems like a self-contained task that can be simple as desired and as hard > as the student wants it to be. > > Nuno > > -----Original Message----- From: Philip Reames

I can step in, if that's ok with you. Nuno -----Original Message----- From: Philip Reames Sent: Saturday, February 17, 2018 1:04 AM To: Davide Italiano ; Nuno Lopes Cc: llvm-dev Subject: Re: [llvm-dev] Missing attribute inference cases Sure, but is anyone willing to mentor? I don't have time. I can advise, but only infrequently. Philip On 02/16/2018 03:47 PM, Davide Italiano wrote:

SGTM On 02/17/2018 03:52 PM, Nuno Lopes wrote: > I can step in, if that's ok with you. > Nuno > > -----Original Message----- From: Philip Reames > Sent: Saturday, February 17, 2018 1:04 AM > To: Davide Italiano ; Nuno Lopes > Cc: llvm-dev > Subject: Re: [llvm-dev] Missing attribute inference cases > > Sure, but is anyone willing to mentor?  I don't have

Hey all, I'm working on adding interprocedural FunctionAttrs optimization ( http://llvm-cs.pcc.me.uk/lib/Transforms/IPO/FunctionAttrs.cpp) to ThinLTO so it does something similar to what LTO is doing ( https://bugs.llvm.org/show_bug.cgi?id=33648). I've hit a problem with how the FunctionAttrs optimization expects linkage types. In ThinLTO since the linkage type is set to External or

Hi Charles, On Tue, Jul 11, 2017 at 12:27 PM, Davide Italiano <davide at freebsd.org> wrote: >> I'm working on adding interprocedural FunctionAttrs optimization >> (http://llvm-cs.pcc.me.uk/lib/Transforms/IPO/FunctionAttrs.cpp) to ThinLTO >> so it does something similar to what LTO is doing >> (https://bugs.llvm.org/show_bug.cgi?id=33648). I've hit a problem

Hi, While working on PR21780, I used "dereferenceable_or_null" metadata and I realized now that it is not correct for my solution to use this metadata type since it might point to an address that it is not dereferenceable but null. I think that we need another new metadata type, something like "dereferenceable" with that we could annotate any load (not just pointer type like

Indeed. But the problem here is that Dinar is trying to keep information after a load/store is removed by instcombine For example: v4sf v = {p[0], p[1], p[2], p[3]}; v4sf v2 = shuffle(v, 0, 0, 2, 2); Some pass comes in and removes the p[3] and p[1]. Now you have smaller code, but lost the ability to use a vector load for all those values + shuffle. The code got scalarized because we lost the

Hi, There is a problem with the handling of alwaysinline functions in Clang: they are not always inlined. AFAIK, this may only happen when the caller is in the dead code, but then we don't always successfully remove all dead code. Because of this, we may end up emitting an undefined reference for an "inline __attribute__((always_inline))" function. Libc++ relies on the compiler

Hello all, I have a custom allocator, and would like to teach LLVM about its semantics. In particular, I would like LLVM to kill allocations that are "dead", similar to dead new in C++. Consider this example: ; ModuleID = '<stdin>' source_filename = "Module" ; Function Attrs: inaccessiblememonly noinline norecurse nounwind declare i8* @alloc(i64)

Dear all, I tried to install gstat package and add the following compilation error : ------------------------> * Installing *source* package 'gstat' ... creating cache ./config.cache checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether

On Thu, Aug 20, 2015 at 7:17 PM, John McCall <rjmccall at apple.com> wrote: > > On Aug 20, 2015, at 5:19 PM, Evgenii Stepanov via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > > Hi, > > > > There is a problem with the handling of alwaysinline functions in > > Clang: they are not always inlined. AFAIK, this may only happen when > > the caller is

Changing the list from cfe-dev to llvm-dev > On 20 Apr 2017, at 4:52 AM, Michael Clark <michaeljclark at mac.com> wrote: > > I’m getting close. I think it may be an issue with an individual intrinsic. I’m looking for the X86 lowering of Instruction::FPToUI. > > I found a comment around the rationale for using a conditional move versus a branch. I believe the predicate logic

Thanks, Andy. I'm not sure how to solve that or my case given the DAG's basic-block limit. Probably CodeGenPrepare or SelectionDAGBuilder...or we wait until after isel and try to split it up in a machine instruction pass. I filed my example here: https://bugs.llvm.org/show_bug.cgi?id=33013 Feel free to comment there and/or open a new bug for the FP_TO_UINT case. On Thu, May 11, 2017 at

Hi Duncan, thanks for the quick answer. Yes I'm sure the runOnModule is being called, and when I dump the functions before exiting the method I can see the AlwaysInline attribute. I'll check InlineAlways.cpp and will reimplement as last resource but I still wonder why this is not working. On Mon, Nov 5, 2012 at 5:03 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Arnaldo,

Hello everyone, I am coding a ModulePass in which I want to add an AlwaysInline attribute to every function so that they can be later inlined by the -always-inline pass. However, the changes to the function seem to be lost after exiting my pass because the AlwaysInline attribute is not in the output LLVM IR. Maybe the function iterator passed by the module object actually points to copies of

On 01/08/2010 02:10 PM, John McCall wrote: > 'llc' is an IR-to-assembly compiler; at -O3 it does some pretty neat > machine-code and object-file optimizations, but it does not apply > high-level optimizations like CSE or inlining. 'opt' is the tool > which does IR-to-IR optimization. A vital clue, but I'm still not getting it: --- gemini:~/Projects/Nil/nil(0)$

Hi, I previously made a proposal for adding a pragma for per-function optimization level control due to a number of requests from our customers (See http://comments.gmane.org/gmane.comp.compilers.clang.devel/28958 for the previous discussion), however the discussion was inconclusive. Some of my colleagues recently had the opportunity to discuss the proposal with a number of people at and