llvm dev - Jan 2018 - 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 mentor, he is leading me
to
> maintain RISCV target, so I have such question, please give me
> suggestions, thanks for your teaching!
>
What you need will highly depend on the architecture. We've worked to
ensure this is effective on x86, but other architectures may need different
approaches or may desire different approaches for performance.

If you read the support article linked in the commit log that describes
retpoline's strategy in much more detail, you can see the criteria that
determine whether it would be effective for a particular architecture.

That said, about the only thing that I suspect would be usefully shared in
terms of code will be the feature flags. The implementation is pretty much
100% target-specific anyways. We could factor a few minor things if it
proves useful.

That said -- I would also only use the term `retpoline` if you in fact
build a return-based trampoline as the mitigation. Other potential
mitigation code sequences would (IMO) be better named something else.

> --
> Regards,
> Leslie Zhai - https://reviews.llvm.org/p/xiangzhai/
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180105/47bd7079/attachment.html>

Hi Chandler,

Thanks for your kind response and teaching!

I just use the pass and function names to take an instance, just like 
Alex taught me that GlobalISel also needs to consider about supporting 
target-specific CCState[1], so it might factor a few minor things, for 
example implement a retpoline framework to fix speculative execution 
issues, code reusable for other targets is better :)

Thanks for your teaching! I will read relative articles and papers more 
carefully!

[1] http://lists.llvm.org/pipermail/llvm-dev/2018-January/120098.html


在 2018年01月05日 16:53, Chandler Carruth 写道:
> On Fri, Jan 5, 2018 at 12:51 AM Leslie Zhai via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto: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 mentor, he is leading
me to
>     maintain RISCV target, so I have such question, please give me
>     suggestions, thanks for your teaching!
>
>
> What you need will highly depend on the architecture. We've worked to 
> ensure this is effective on x86, but other architectures may need 
> different approaches or may desire different approaches for performance.
>
> If you read the support article linked in the commit log that 
> describes retpoline's strategy in much more detail, you can see the 
> criteria that determine whether it would be effective for a particular 
> architecture.
>
> That said, about the only thing that I suspect would be usefully 
> shared in terms of code will be the feature flags. The implementation 
> is pretty much 100% target-specific anyways. We could factor a few 
> minor things if it proves useful.
>
> That said -- I would also only use the term `retpoline` if you in fact 
> build a return-based trampoline as the mitigation. Other potential 
> mitigation code sequences would (IMO) be better named something else.
>
>
>     --
>     Regards,
>     Leslie Zhai - https://reviews.llvm.org/p/xiangzhai/
>
>
>
>     _______________________________________________
>     LLVM Developers mailing list
>     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-- 
Regards,
Leslie Zhai - https://reviews.llvm.org/p/xiangzhai/