- User Since
- Jan 21 2013, 11:58 AM (226 w, 22 h)
Fri, May 19
Thu, May 11
@hfinkel Oh, my bad--I now remember that this came up long ago...
I'd be okay (even happy! :) ) if you add a @llvm.safe.load.<ty> intrinsic that never has UB, and returns undef if the address passed to it is not dereferenceable. That intrinsic could then be marked speculatable. If needed, we could even implement the intrinsic by trying to read from the address passed in, and by catching the SIGSEGV or SIGBUS, if any.
@sanjoy Since D20116 is in, is there any reason to avoid having a !speculatable on load instructions? It can be emulated anyway by defining a class of @load.x functions marked speculatable and their return value dereferenceable, so there is no loss of soundness.
Apr 21 2017
Apr 19 2017
Apr 17 2017
The real question is established bindings like the OCaml and python bindings -- would they be willing to use this API with breaking changes?
Jan 25 2017
Jan 4 2017
Seems good to me!
Nov 12 2016
Nov 11 2016
@sanjoy OK, I understand now. In a nutshell, our disagreement was in whether dead code in IR can affect semantics of live code. This doesn't strike me as particularly bad (even after looking at your examples--clearly they shouldn't use !unconditionally_dereferenceable, but that doesn't mean it's not useful elsewhere), but you clearly have more experience here, so I won't argue that my approach is viable for upstream.
Nov 10 2016
@sanjoy Your example is being transformed as expected, from my POV. The idea is that an unconditionally dereferenceable load cannot be moved across a store that may-alias the pointer, and this lets one initialize it safely. Other than immediately after allocation, a pointer which is ever loaded like that must always be dereferenceable.
Stale and no time to update in sight.
Actually updated the diff this time.
Loads of pointers are not hoisted for some reason, so keeping the pointer-related metadata makes no sense for now. Amended patch to be less aggressive and only keep !invariant.load.
The source level rule is as follows: I have a memory-safe language with region-based memory management. Once an object is constructed, pointers to it are guaranteed by the frontend to live no longer than the object. Thus, most* pointers constructed, even in dead code, can be dereferenced at any time when it is possible at all to construct it.
Oct 4 2016
Oct 3 2016
Added explanatory comment
Maybe ppc32 big endian for the testcase?
It is quite regretful that this change comes without tests, but I wasn't able to trick any of the existing in-tree bi-endian backends into generating a __muldi3 sequence that I need to match against. Even worse, just unconditionally swapping the registers doesn't break any of the tests, implying that this branch wasn't tested in the first place (and also that there's nothing I can easily modify).
Sep 30 2016
Sep 20 2016
@jpdeplaix can you please test the updated patch also?
Sep 9 2016
@jpdeplaix Can you please also test the changes? Once I get ACK from you I will commit.
Sep 8 2016
I don't see any point in having them separately in git either, it is just confusing since you are making logically one change to one component...
Please just fold these three patches into one.
But doesn't OCAML_STDLIB_PATH include /usr? So you would be installing to /usr/local/usr/lib/ocaml with the default config, unless I'm missing something.
Sep 5 2016
Sep 4 2016
Aug 30 2016
@majnemer ping? I am also interested in this.
Aug 23 2016
Aug 22 2016
Jul 24 2016
@echristo Assuming this works as one would expect, this is a massive improvement. However, I'm not completely certain of all subtle build system behavior. Do you see any potential downsides?
@nagisa, yes, I think that will work.
@nagisa, they are deliberately inline and deliberately unavailable for FFI use. After your change, every single executable statically linking to Target will link every individual backend, which makes them at least 200-500MB larger and increases link times by 10-60s (ballpark numbers).
Jul 20 2016
@deadalnix, So, no aggregate getters at all? That's unacceptable.
Jun 21 2016
Jun 15 2016
Jun 14 2016
Jun 13 2016
This is great!
Jun 11 2016
Aggregate getters LGTM
As per IRC discussion, some renaming
May 23 2016
May 10 2016
May 3 2016
Apr 27 2016
Why do you say adding a single attribute is the most common use-case? I'd expect the most common use to be to be creating a function definition/declaration/call instruction from scratch, with a given set of specified function/parameter/return-value attributes. Which is ideally suited for constructing an attribute set, and then calling a setter to place it onto the instruction. Why do you think RMW operations would be primary?
@jyknight I strongly dislike exposing AttributeSet. What is the proposed usecase? FFI calls are expensive and using AttributeSet requires at least three operations (RMW) instead of one (Add) for the most common case (adding a single attribute). Further, AttributeSet is not easily interrogated; to get the full list of attributes, I propose (in the future) to add a function that returns an array of LLVMAttributeRef, which is again much nicer to bindings.
Apr 26 2016
I have no more objections.
One thing I would like to have right away is a way to get the kind of an attribute. Looks good otherwise.
Apr 25 2016
LGTM, but please commit once you are certain that tests are pass.
Apr 19 2016
Apr 14 2016
Will target dependent attributes be covered by the API (like "no-sse")? Or is it only the regular attributes?
Apr 13 2016
@rafael The C enum doesn't help much since frontends using libffi to bind to the C API have to duplicate the enum in the binding. Whereas, the function will work for at least removed attributes (it can return 0 and signal an error to the frontend).
@echristo What about exposing the bare key-value metadata interface? It itself can be stable, and frontends could use it before anything more specific is stabilized.
@rafael I don't understand. How are you proposing frontends using LLVM-C emit functions with attributes?
LGTM. I agree with @Wallbraker that the functions accepting AttrKindIDs will have to have their ABI versions bumped.
Apr 10 2016
Yes, please remove those parts and re-enable the tests.
Apr 8 2016
Apr 6 2016
deadalnix, does the test look OK to you?
Actually, can you please add a test? The main function of llvm-c-test/echo.cpp seems to be a suitable place to set and then retrieve a diagnostic handler.
Apr 5 2016
Apr 4 2016
Apr 3 2016
The reason the table exists is for bindings. Without LLVMGetValueKind(), a binding that wishes to introspect an instruction has to call the multitude of LLVMIsA* functions in sequence, which is:
- Slow (many bindings use libffi)
- Usually cannot be inlined (see 1)
- Fragile and hostile to upgrades of LLVM, as there isn't even an easy way to figure out the type of the value that broke the check