similar to: Ensuring that dead allocations from a custom allocator are killed by LLVM

I had this on my TODO list for a while, but the recent introduction of inaccessiblememonly makes it suddenly more urgent, as there is a risk to waste effort in duplicated work and/or end up with suboptimal solutions. I collected 2 use cases for inaccessiblememonly : - Allocation like functions. - Runtime functions for managed languages, that touch state that the program itself can never touch

> On Jan 4, 2016, at 9:55 AM, Amaury SECHET via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > 2016-01-04 18:21 GMT+01:00 Philip Reames <listmail at philipreames.com <mailto:listmail at philipreames.com>>: > On 01/04/2016 07:32 AM, Amaury SECHET wrote: >> After a bit more investigation, it turns out that because %0 is stored into %1 (after

On Mon, Feb 22, 2016 at 9:40 PM, Andrew Trick <atrick at apple.com> wrote: > I actually see fences as a proxy for potential inter-process > communication and I/O. It's important that any opaque library call > could contain a fence. This makes perfect sense to me now, especially if you want to use @trap_on for safety checks. Without re-ordering restrictions, a failed @trap_on

On 01/04/2016 07:32 AM, Amaury SECHET wrote: > After a bit more investigation, it turns out that because %0 is stored > into %1 (after bitcast) and so %3 may have access to it and clobber it. Can you give a bit more context? I'm not sure which of the examples you're talking about. > > After a bit of thought, it is correct in the general case, but > definitively something

A while back, we introduced new attributes to model functions which read and wrote from locations not otherwise visible in the IR. The motivation was to enable much more aggressive aliasing around such calls. Since that time, we've reverted the original patch and AFAIK we have no transformation or analysis passes in tree which use this information. Given this, I don't think it's

2015-12-26 18:32 GMT+01:00 Philip Reames <listmail at philipreames.com>: > On 12/26/2015 02:17 AM, Amaury SECHET via llvm-dev wrote: > > I'm trying to fix that bug: https://llvm.org/bugs/show_bug.cgi?id=20049 > > It turns out this is the kind of optimization that I really need, as when > it isn't done, all kind of other optimizations opportunities down the road

On 4/29/20 4:12 PM, Reid Kleckner via llvm-dev wrote: > On Tue, Apr 28, 2020 at 12:58 PM Ejjeh, Adel via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Specifically, I want to be able to know when a called function does not >> have any side effects (e.g. math library functions like sqrt) >> > > Apologies for the pedantry, but I believe sqrt may

> > I'm not sure why this is an issue. Yes, these two intrinsics depend > on the current rounding mode according to the C standard, and yes, > LLVM in default mode assumes that the current rounding mode is the > default rounding mode. But the same holds true for many other > intrinsics and even the arithmetic IR operations like add. Any other intrinsic, like `floor`,

Hi! I'm interested in what attributes in LLVM mean, specifically how to say that the result is always the same for the given input parameters. The main thing would be to merge two calls with the same parameters when the function is declared but not defined. (just like two stores). I'll call this property mergability. %1 := call @test(%0) %2 := call @test(%0) and the optimization would

Some clarification after getting feedback from Craig Topper…. It’s probably best to say in the documentation that the llvm.nearbyint and llvm.rint functions “assume the default rounding mode, roundToNearest”. This will allow the optimizer to transform them as if they were rounding to nearest without requiring backends to use an encoding that enforces roundToNearest as the rounding mode for these

> > The only issue I see is that since we also assume FP operations have no > side effects by default there is no difference between llvm.rint and > llvm.nearbyint. I wouldn’t have a problem with dropping llvm.rint > completely. The forthcoming C standard ( http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2454.pdf, 7.12.9.8) defines new function, `roundeven`, which implements

> > One concern with replacing llvm.rint and llvm.nearbyint with > llvm.roundeven makes it difficult to turn back into a libcall if the > backend doesn't have an instruction for it. You can't just call the > roundeven library function since that wouldn't exist in older libm > implementations. So ideally you would know which function was originally > used in the

Hi All I am writing a pass which requires checking dependences, and am having trouble dealing with function calls. Specifically, I want to be able to know when a called function does not have any side effects (e.g. math library functions like sqrt), and was wondering if there are attributes that specify this behavior (I know there is the ‘noread’ attribute but wasn’t sure if there’s something

Hi László, On 8/13/20 5:21 PM, László Radnai via llvm-dev wrote: > (Sorry I clicked reply instead of reply to all) > I'm fighting with my email client, I hope the quoted text contains > what I want it to contain. > > ---------- Forwarded message ---------- > From: László Radnai <radlaci97 at gmail.com> > Date: Fri, 14 Aug 2020 00:11:35 +0200 > Subject:

Hi Andy, Responses inline: On Mon, Feb 22, 2016 at 10:08 AM, Andrew Trick <atrick at apple.com> wrote: >> By memory barrier, do you mean things like fences? > That’s right. Conservatively, I would not hoist at the LLVM level past > opaque non-readonly calls or fences. Just for curiosity: why do you care about memory fences specifically? > I've begun to think that

I'm trying to fix that bug: https://llvm.org/bugs/show_bug.cgi?id=20049 It turns out this is the kind of optimization that I really need, as when it isn't done, all kind of other optimizations opportunities down the road are not realized as they are not exposed. I have no idea where to start digging for this. I assume there is some kind of interaction between memory dependency and alias

Hi Sanjoy, Thanks for feedback! As for memory effects, currently I use " inaccessiblememonly " for it. It allows to prove that it doesn't alias with any other load/store in the function, but doesn't allow CSE to eliminate it. It is not actually super-cool, because there is no way that we can safely hoist it out of loop (and sometimes we want to, for example to make unswitching).

Hi folks, here is a link to the proposal that we've been working on lately: https://docs.google.com/document/d/16GVtCpzK8sIHNc2qZz6RN8amICNBt vjWUod2SujZVEo/edit?usp=sharing But for the record, I also paste it here. Feedback will be really appreciated!

> On Mar 19, 2018, at 7:27 PM, Piotr Padlewski via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > Hi folks, > > here is a link to the proposal that we've been working on lately: > https://docs.google.com/document/d/16GVtCpzK8sIHNc2qZz6RN8amICNBtvjWUod2SujZVEo/edit?usp=sharing

Hello Everyone, I want to raise a discussion about @llvm.experimental.guard intrinsic and reasons why we should give up using it. Here is an alternative approach to representation of guards that resolves some of fundamental flaws that the current guards have. Basically, this intrinsic was introduced to model the following situation: we want to check that some condition is true, and if it's