[PATCH] D14497: [FunctionAttrs] Detect printf-like functions and propagate readnone+nocapture to variadic operands

Silviu Baranga via llvm-commits llvm-commits at lists.llvm.org
Fri Nov 13 05:03:18 PST 2015


Hi James,
 
Ok, that makes sense.
 
So this is a work-around for the lack of attributes for varargs in llvm IR (which affects mostly library functions?).
 
There might be alternative solutions (either allowing attributes for .. or being able to mark the entire function as nocapture),
but I can’t tell if that would be worth it or not… This is something that might be worth thinking about.
 
I’ll have to leave this review to someone else, I wouldn’t feel confident enough to give a lgtm in this area.
 
Cheers,
Silviu
 
From: James Molloy [mailto:james at jamesmolloy.co.uk] 
Sent: 12 November 2015 16:41
To: reviews+D14497+public+665d022658dbb442 at reviews.llvm.org; Silviu Baranga; James Molloy; chandlerc at gmail.com; mcrosier at codeaurora.org; hfinkel at anl.gov; david.majnemer at gmail.com
Cc: llvm-commits at lists.llvm.org
Subject: Re: [PATCH] D14497: [FunctionAttrs] Detect printf-like functions and propagate readnone+nocapture to variadic operands
 
Hi Silviu,
 
The problem is that most of the compiler expects function argument attributes to be the same as call operand attributes. Most of FunctionAttrs is devoted to inferring and adding attributes to function arguments (see most of the code below my change, where it finds nocapture). For varargs, there is no such function argument as the number of call operands are greater than the number of function arguments. There's just no representation for "..." to have attributes in the IR.
 
As to why we check for LibFuncs, that's because it's possible to take a variable argument and do whatever you like with it. You could capture it, store it to a global, write over it... In fact, vscanf() does this exactly and writes into its variable arguments.
 
James
 
On Thu, 12 Nov 2015 at 16:11 silviu.baranga at arm.com via llvm-commits <llvm-commits at lists.llvm.org> wrote:
sbaranga added a subscriber: sbaranga.
sbaranga added a comment.

Hi James,

Do you know what other parts of the compiler are preventing us from figuring out the readonly/nocapture attributes?

If we could use the existing infrastructure for this we might get a more general solution (I'm not saying that's possible).

Cheers,
Silviu


================
Comment at: lib/Transforms/IPO/FunctionAttrs.cpp:847
@@ +846,3 @@
+  case LibFunc::vsnprintf:
+    return true;
+  }
----------------
Wouldn't it be enough to have readonly/nocapture? Why do we need to test for library functions?


Repository:
  rL LLVM

http://reviews.llvm.org/D14497



_______________________________________________
llvm-commits mailing list
llvm-commits at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151113/36baa70b/attachment.html>


More information about the llvm-commits mailing list