- User Since
- Jan 21 2013, 11:58 AM (247 w, 1 d)
Sun, Oct 15
Indeed, needs a test.
I think it's fine to land this but only if we introduce LLVMMetadataRef at the same time, otherwise it becomes nearly impossible to understand for downstream.
Do I understand it correctly that LLVMMetadataRef is going to effectively become a subtype of LLVMValueRef? I.e. it is (and will be, indefinitely) legal to pass an LLVMMetadataRef anywhere you can pass LLVMValueRef, but not vice versa?
I'm not the one to sign off on this diff, sorry.
I agree with pretty much all @mgorny says.
Fri, Oct 13
Sun, Oct 1
Aug 22 2017
Jul 29 2017
Jul 28 2017
The problem is that I can't pass -DNDEBUG to the build because it does not respect CFLAGS.
message(FATAL_ERROR "LLVM_OCAML_OUT_OF_TREE cannot be enabled while on Debug mode. Use -DCMAKE_BUILD_TYPE=Release instead.")
Otherwise, the executables fail to run being unable to locate
the libraries (unless the LLVM directory is explicitly added to
Jul 27 2017
Jul 26 2017
Jun 28 2017
Cosmetic change in debug output.
Jun 23 2017
Jun 22 2017
Addressed review comments
Jun 21 2017
LGTM, but I'd still like to hear from @majnemer
Jun 20 2017
@pcwalton But I agree that it's better to change both sides of the __probestack ABI to eliminate the argument and the spill (on x86_64), of course.
@pcwalton No, both the spill and the "magic" number are necessary. See https://reviews.llvm.org/D9858. ebx is the size of the frame, and 0x1000 is the probe interval to be performed (in other words, page size).
It looks like you inadvertently included an entire copy of D34387 here.
Jun 5 2017
Jun 4 2017
Jun 2 2017
May 30 2017
Sure, unless you want to get all contained types as an array.
I don't think anyone ever had a goal of covering the entire C++ API, the binding is produced demand-side.
@TyanNN What's wrong with using element_type then?
@deadalnix The use case is the same. The current API can assert, the one I suggest can not.
On second thought I would prefer the OCaml interface to have a single function returning an array, since this is safer and easier to use.
May 19 2017
May 11 2017
@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.