search for: speculatable

FYI, see also the previous discussion about "speculatable": http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/064426.html I think such an attribute should be added. In the thread which lead up to that thread, I proposed using more fine-grained attributes and Michael rightly pointed out the problem with that: you'd need one for every possi...

...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 be something like (%2).replaceUsesWith((%1)). I think it's related to speculatable & readnone in LLVM, (if I understood well, it's the same as GCC's __attribute__((pure)), but I'm not sure whether there are edgecases where the mergability is not equivalent. I've seen somewhere that maybe malloc has these attributes, but it surely cannot be merged. This is bec...

A patch is attached. Not sure I'm happy with this due to the aforementioned orthogonality concerns, but I really don't have any better ideas. If anyone does, feel free to offer them, I don't mind throwing this patch into the trash. (Also, not happy with the name, using "speculatable" as Nick suggested, for the lack of other options. If the name stays I'll add it to the documentation.) Regarding auditing the intrinsics - I'd prefer to do this in stages. Here I'm just preserving the current behavior by marking intrinsics that used to be explicitly handled in is...

...aces around this case. > Not sure I’m happy with this due to the aforementioned orthogonality > concerns, but I really don’t have any better ideas. If anyone does, feel > free to offer them, I don’t mind throwing this patch into the trash. > > (Also, not happy with the name, using “speculatable” as Nick suggested, > for the lack of other options. If the name stays I’ll add it to the > documentation.) That reminds me, the patch needs to come with an update to LangRef.rst. > Regarding auditing the intrinsics – I’d prefer to do this in stages. Sounds fine. I'd like Eric to ta...

...; with the same arguments which dominate the call-site at "X". However, there are some cases that this would not be able to optimize. For example, if we have two csecandidates ("X" and "Y") which do not dominate one another. This is solvable using another attribute: speculatable. This attribute would tell us that we can hoist the call out of arbitrary conditions. This would allow us to move our csecandidate call-site to the common dominator of "X" and "Y" and RAUW. On Fri, Dec 4, 2015 at 8:54 AM, Krzysztof Parzyszek via llvm-dev < llvm-dev at li...

...halts but may have undefined behavior is important. > While the two are not orthogonal, it's similar to the situation with > "readnone" and "readonly". Does that sound reasonable? > You're entirely right. I forgot about undefined behaviour. If you want a 'speculatable' attribute, I would review that patch. Please audit the intrinsics (at least the target-independent ones) and appropriate library functions for whether you can apply this attribute to them. I think the only optimization that it can trigger is that "isSafeToSpeculativelyExecute" return...

...ase. > Not sure I'm happy with this due to the aforementioned orthogonality > concerns, but I really don't have any better ideas. If anyone does, > feel free to offer them, I don't mind throwing this patch into the trash. > > (Also, not happy with the name, using "speculatable" as Nick > suggested, for the lack of other options. If the name stays I'll add > it to the > documentation.) That reminds me, the patch needs to come with an update to LangRef.rst. > Regarding auditing the intrinsics - I'd prefer to do this in stages. Sounds fine. I...

...BL.0042: ; preds = %BL.0005, %entry ret void } ; Function Attrs: norecurse readnone define dllexport void @burst.initialize(i8* (i8*)* nocapture readnone %callback) local_unnamed_addr #1 !ubaa. !0 { entry: ret void } ; Function Attrs: nounwind readnone speculatable willreturn declare float @llvm.pow.f32(float, float) #2 attributes #0 = { nofree } attributes #1 = { norecurse readnone } attributes #2 = { nounwind readnone speculatable willreturn } !ubaa.Burst.Compiler.IL.Tests.VectorsMaths\2FFloatPointer.0 = !{!0, !0, !0, !0} !0 = !{i1 false} !1 = !{i1 true,...

...t; I'll call this property mergability. >>  > >>  > %1 := call @test(%0) >>  > %2 := call @test(%0) >>  > >>  > and the optimization would be something like (%2).replaceUsesWith((%1)). >>  > >>  > I think it's related to speculatable & readnone in LLVM, (if I >>  > understood well, it's the same as GCC's __attribute__((pure)), but I'm >>  > not sure whether there are edgecases where the mergability is not >>  > equivalent. >>  > >>  > I've seen somewhere tha...

Hello, OpenCL C specifies that instructions should not trap (it is "discouraged" in the specs). If they do, it's vendor-specific how the hardware exceptions are handled. It might be also the case with some other (future) languages targeting "streamlined" parallel accelerators in an heterogeneous setting. At least CUDA comes to mind. What about OpenACC and the new OpenMP,

Of course frontends are free to put attributes, but it would be nice if optimizations actually used them. ;-) My use case is that of proprietary frontend that happens to know some library function calls - which are only resolved at link time - have no side effects and are safe to execute speculatively, and wants to tell the optimizer it can move them around however it likes. I'll gladly submit

...y: int foo(bool C) available_externally { if (C) ((int *) null)++; // UB ret 42; } void bar() { if (<some cond>) foo(true); } Now, normally you can just delete the `if (C)` branch in foo, and it would become just a `ret 42`, and would look like it is speculatable above the `<some cond>` check. But if you then link with an -O0 version, you'll have introduced UB if `<some cond>` is always false at runtime. Today this won't happen since we don't speculate `readnone nounwind` functions, but could become a problem in the future. -- San...

...>> } >> >> ; Function Attrs: norecurse readnone >> define dllexport void @burst.initialize(i8* (i8*)* nocapture readnone >> %callback) local_unnamed_addr #1 !ubaa. !0 { >> entry: >> ret void >> } >> >> ; Function Attrs: nounwind readnone speculatable willreturn >> declare float @llvm.pow.f32(float, float) #2 >> >> attributes #0 = { nofree } >> attributes #1 = { norecurse readnone } >> attributes #2 = { nounwind readnone speculatable willreturn } >> >> !ubaa.Burst.Compiler.IL.Tests.VectorsMaths\2FFloatPo...

...l(dbglabelPtr, args, ""); } And before my pass finish, I print the IR, it shows I successfully add the intrinsic %5 = load i32 (i32, i32)*, i32 (i32, i32)** %1, align 8, !dbg !35, !ppp.load !36 call void @llvm.dbg.label(metadata !36), !dbg !37 ... ; Function Attrs: nounwind readnone speculatable willreturn declare void @llvm.dbg.label(metadata) #1 But, when I use llvm-dis to disassemble the .bc generated by opt, it ignore the code I insert: invalid llvm.dbg.label intrinsic variable call void @llvm.dbg.label(metadata !36), !dbg !37 !36 = !{!"dbg1", !"dbgfromLoad"} ll...

...able_or_null - see previous nounwind - currently implemented in PruneEH, missing in new pass manager -- this one will get fixed in the near future Other cases I just noticed... noreturn -- useful for exception throw wrappers allocsize -- useful for allocation wrappers writeonly -- useful for AA speculatable - useful for speculation, LICM, PRE, etc... Untrusted Declarations In several cases, we check hasExactDefinition before checking properties of the function declaration (such as return type). To my knowledge, facts on declarations are valid even in the place of derefinement. This results in...

...hen sum.sext is provably poison. However, we do care about taking into the _possibility_ of sum.sext being poison, which is really just a more precise way of saying that we care about taking into the possibility of sum.sext being commuted into (sext(x) * sext(y)) (in which case the division is not speculatable). And we want to do this with enough formalism in place so that we can write correct checking interpreters, fuzzers etc. > I would suggest: > 1. Make undef an instruction which produces an arbitrary but consistent result of its type. > 2. Revisit most of the transformations that actually...

...d in PruneEH, missing in new pass manager -- >> this one will get fixed in the near future >> >> Other cases I just noticed... >> noreturn -- useful for exception throw wrappers >> allocsize -- useful for allocation wrappers >> writeonly -- useful for AA >> speculatable - useful for speculation, LICM, PRE, etc... >> >> >> >> Untrusted Declarations >> >> In several cases, we check hasExactDefinition before checking properties of >> the function declaration (such as return type). To my knowledge, facts on >> declarati...

...e previous > > nounwind - currently implemented in PruneEH, missing in new pass > manager -- this one will get fixed in the near future > Other cases I just noticed... noreturn -- useful for exception throw wrappers allocsize -- useful for allocation wrappers writeonly -- useful for AA speculatable - useful for speculation, LICM, PRE, etc... > *Untrusted Declarations* > > In several cases, we check hasExactDefinition before checking > properties of the function declaration (such as return type). To my > knowledge, facts on declarations are valid even in the place of > de...

...ue then it is UB. > > But then you're saying dead code (code that would not actually execute > in the original program) can affect program behavior, and: "if (false) > X;" is not a no-op for some values of X. It is in this respect that > your proposal is similar to the speculatable proposal. > > -- Sanjoy > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

2017-04-06 17:57 GMT+02:00 Sanjoy Das <sanjoy at playingwithpointers.com>: > Hi Piotr, > > On April 6, 2017 at 2:36:53 AM, Piotr Padlewski > (piotr.padlewski at gmail.com) wrote: > > I disagree, I find it different than the patch you mentioned. We don't > have > > any problems with code like this: > > > > ptr = load i8*, i8** %ptrptr,