search for: d1981

...ually using the new intrinsics and can provide real concrete >>>> feedback. >>> >>> I want this to be clear when we expose the intrinsics to other >>> developers. I’ve been making an effort to improve the docs: >>> http://llvm-reviews.chandlerc.com/D1981. Please let me know where >>> clarification is needed >> I responded in the review. The only big thing that might be worth >> discussion here is the "full resume" semantics which are mentioned at >> the very end. This seemed to disagree with our previous di...

...revisit this once I'm >> actually using the new intrinsics and can provide real concrete >> feedback. > > I want this to be clear when we expose the intrinsics to other > developers. I’ve been making an effort to improve the docs: > http://llvm-reviews.chandlerc.com/D1981. Please let me know where > clarification is needed I responded in the review. The only big thing that might be worth discussion here is the "full resume" semantics which are mentioned at the very end. This seemed to disagree with our previous discussion. Let me know if you'...

...any more. Let's move on. We can revisit this once I'm actually using the new intrinsics and can provide real concrete feedback. I want this to be clear when we expose the intrinsics to other developers. I’ve been making an effort to improve the docs: http://llvm-reviews.chandlerc.com/D1981. Please let me know where clarification is needed. -Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131023/d3cd1bda/attachment.html>

...nd become reliant on a quirk of the implementation you >> later want to change. > > I don't think the intrinsic names will be able to capture their > semantics. I think that's why we need documentation, which I've been > working on: http://llvm-reviews.chandlerc.com/D1981. > > For example, the "stackmap" intrinsic isn't really a stack map, it's > something that allows generation of a stack map in which the entries > don't actually need to be on the stack... confusing, but still a good > name I think. "stack map" is a...

...on. We can revisit this once I'm actually using the new intrinsics and can provide real concrete feedback. >> >> >> I want this to be clear when we expose the intrinsics to other developers. I’ve been making an effort to improve the docs: http://llvm-reviews.chandlerc.com/D1981. Please let me know where clarification is needed > I responded in the review. The only big thing that might be worth discussion here is the "full resume" semantics which are mentioned at the very end. This seemed to disagree with our previous discussion. Let me know if you're e...

...do is misconstrue your intent and become reliant on a quirk of the implementation you later want to change. I don't think the intrinsic names will be able to capture their semantics. I think that's why we need documentation, which I've been working on: http://llvm-reviews.chandlerc.com/D1981. For example, the "stackmap" intrinsic isn't really a stack map, it's something that allows generation of a stack map in which the entries don't actually need to be on the stack... confusing, but still a good name I think. >> But the patchpoint does not have to be a ca...

Ok I see. Of course, at runtime, it's enough for dynamic linking or for deoptimization. However, wmkit acts both as a jit and as an aot. For the aot, it means that I can not use patchpoint and that I should have two different compilation strategy. It's not so difficult, but in this case, I can not use patchpoints to generate gc's stackmap for the aot (basically, I think that I could

Adding Gael as someone who has previously discussed vmkit topics on the list. Since I'm assuming this is where the GC support came from, I wanted to draw this conversation to the attention of someone more familiar with the LLVM implementation than myself. On 10/22/13 4:18 PM, Andrew Trick wrote: > On Oct 22, 2013, at 3:08 PM, Filip Pizlo <fpizlo at apple.com > <mailto:fpizlo