similar to: FYI, we've posted a component of Spectre mitigation on llvm-commits

On Fri, Jan 5, 2018 at 12:51 AM Leslie Zhai via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi LLVM developers, > > Does it need to implement <Target>RetpolineThunksPass, > `getOpcodeForRetpoline`, `EmitLoweredRetpoline`, etc. for other Targets? > Or does it also need to implement `RetpolinePic` to inherit from > <Target> for LLD's Backends? Alex is my

Thanks for the notification, Chandler. I also wanted to note that I’ve just posted another component for Spectre mitigation (variant 1), see https://reviews.llvm.org/D41760 and https://reviews.llvm.org/D41761. I believe this is completely complementary to the retpoline mitigation you pointed to at https://reviews.llvm.org/D41723#, which is targeted at mitigating variant 2. Thanks, Kristof On 4

On 4 January 2018 at 10:23, Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Sending a note here as this seems likely to be of relatively broad interest. > > Thread: > http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180101/513630.html > > Review link: > https://reviews.llvm.org/D41723# It seems the review link is getting wider coverage

The folks working on phab are busily propping it up. It should be relatively healthy now. On Thu, Jan 4, 2018 at 9:20 AM Alex Bradbury via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 4 January 2018 at 10:23, Chandler Carruth via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Sending a note here as this seems likely to be of relatively broad > interest. >

> On Jan 4, 2018, at 04:23, Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Sending a note here as this seems likely to be of relatively broad interest. It looks like this is producing code of the following form. call next loop: pause jmp loop next: mov [rsp], r11 ret As I understand it, the busy loop is to cause the speculative execution to be trapped

On 4 January 2018 at 16:49, Chandler Carruth <chandlerc at gmail.com> wrote: > The folks working on phab are busily propping it up. It should be relatively > healthy now. Many thanks to those good people! Have you considered developing the patch description into a blog post for blog.llvm.org, maybe after the patch lands? Best, Alex

On Jan 4, 2018, at 11:52, Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Thu, Jan 4, 2018 at 12:31 PM Stephen Checkoway via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> As I understand it, the busy loop is to cause the speculative execution to be trapped in the loop. Was something like ud2 considered? I presume that would stop the speculative

Awesome, replied. We've been working on similar things, but didn't have them ready-to-publish due to slightly lower urgency (there are reasonable ways to locally mimic these kinds of things in sensitive areas like the Linux kernel, and even finding code patterns for variant #1 is substantially harder). We have some significantly different APIs we'd like to discuss here based on

On Thu, Jan 4, 2018 at 12:31 PM Stephen Checkoway via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Jan 4, 2018, at 04:23, Chandler Carruth via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Sending a note here as this seems likely to be of relatively broad > interest. > > It looks like this is producing code of the following form.

Sending a note here as this seems likely to be of relatively broad interest. Thread: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180101/513630.html Review link: https://reviews.llvm.org/D41723# -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180104/78682480/attachment.html>

Hi Leslie, On 20 December 2017 at 10:51, Leslie Zhai via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Sorry, I am apprentice of lowRISC, and meet new bug when porting GlobalISel > to RISCV target > https://github.com/xiangzhai/llvm/commit/b3f91ea54d9fee0ef7e73a32c6b8456bbe252811 > > > In file included from >

-debug-only only works on builds with assertions enabled. Your version string says optimized build and doesn’t mention assertions. On Thu, Dec 21, 2017 at 7:15 AM Leslie Zhai via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi LLVM developers, > > llc -march=mips -debug-only=isel was able to work in Nov 8 2017 > https://reviews.llvm.org/D39723 > > But it doesn't

在 2017年04月26日 16:51, Simon Dardis 写道: > Hi Leslie, > > I've been seeing those failures as well (I own those buildbots). Like yourself, I'm a bit > uncertain as to why they're occurring. I'm currently investigating. I suspect it's a case > that the build directory has gone stale. Perhaps! and buildbots cover how many LLVM Backend targets? thanks! > >

Hi LLVM developers, Thank Daniel Sanders, Aditya Nandakumar and Justin Bogner's Tutorial[1]: Head First into GlobalISel about how to port, and Aditya took BPF target as a simple instance: bool BPFCallLowering::lowerReturn(MachineIRBuilder &MIRBuilder,                                   const Value *Val, unsigned VReg) const {   assert(!Val == !VReg && "Return value

Hi LLVM developers, llc -march=mips -debug-only=isel was able to work in Nov 8 2017 https://reviews.llvm.org/D39723 But it doesn't work now: $ clang --version LLVM China clang version 6.0.0 (git at github.com:llvm-mirror/clang.git 9b7b03045ee9b5622028537266aafeb9ea218ac1) (git at github.com:llvm-mirror/llvm.git 3a26601a88394c02603b8756527c55df9ab94d78) (based on LLVM 6.0.0svn) Target:

Reported https://bugs.llvm.org/show_bug.cgi?id=38911 Thanks, Leslie Zhai 在 2018年09月11日 16:55, Dimitry Andric 写道: > Hi Leslie, > > The problem really lies in the OpenJDK code, as it is attempting to > write to a const object. If this seems to work with certain compiler(s) > and optimization settings, it is just luck. :-) > > Here is a reduced example, which shows the

Hi LLVM developers, Buildbot clang-cmake-mips False Positive? I have looked build failures: http://lab.llvm.org:8011/builders/clang-cmake-mips/builds/3277 http://lab.llvm.org:8011/builders/clang-cmake-mips/builds/3278 http://lab.llvm.org:8011/builders/clang-cmake-mips/builds/3279 http://lab.llvm.org:8011/builders/clang-cmake-mips/builds/3281

Hi LLVM developers, After Remove int_x86_sse2_psll_dq_bs and int_x86_sse2_psrl_dq_bs intrinsics. The builtins aren't used by clang. https://reviews.llvm.org/rL229069 there was no Intrinsic::x86_sse2_psrl_dq any more, then how to migrate: Function *F = Intrinsic::getDeclaration(TheModule, Intrinsic::x86_sse2_psrl_dq); Result = Builder.CreateCall(F,

Hello Leslie, The errors coming from the gnu assembler are due to the file being assembled in Arm state, to get rid of the errors you'll either need to put a .thumb directive in the file, or pass -mthumb to the assembler via arm-linux-gnu-gcc -Wa,-mthumb (I think). I'm not able to explain what you are seeing in your print out as it doesn't quite match the map file. Looking at your

Hi Matthias, Thanks for your hint! It is just for learning and practicing for me, just like migrate DragonEgg http://lists.llvm.org/pipermail/llvm-dev/2017-September/117201.html the motivating is for learning from GCC and LLVM developers. 在 2017年12月19日 10:07, Matthias Braun 写道: > > >> On Dec 18, 2017, at 9:52 AM, Leslie Zhai via llvm-dev >> <llvm-dev at lists.llvm.org