<div dir="ltr"><div>Also, looks like this committer's email bounces.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 28, 2019 at 10:22 PM Mail Delivery Subsystem <<a href="mailto:mailer-daemon@googlemail.com">mailer-daemon@googlemail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<table cellpadding="0" cellspacing="0" class="gmail-m_-8686308459090970459email-wrapper" style="padding-top:32px;background-color:rgb(255,255,255)"><tbody>
<tr><td>
<table cellpadding="0" cellspacing="0"><tbody>
<tr><td style="max-width:560px;padding:24px 24px 32px;background-color:rgb(250,250,250);border:1px solid rgb(224,224,224);border-radius:2px">
<img style="padding: 0px 24px 16px 0px; float: left;" width="72" height="72" alt="Error Icon" src="cid:169359141fdd3f2f3341">
<table style="min-width:272px;padding-top:8px"><tbody>
<tr><td><h2 style="font-size:20px;color:rgb(33,33,33);font-weight:bold;margin:0px">
Message not delivered
</h2></td></tr>
<tr><td style="padding-top:20px;color:rgb(117,117,117);font-size:16px;font-weight:normal;text-align:left">
Your message couldn't be delivered to <a style="color:rgb(33,33,33);text-decoration:none"><b>jiwang@tilera.com</b></a> because the remote server is misconfigured. See technical details below for more information.
</td></tr>
</tbody></table>
</td></tr>
</tbody></table>
</td></tr>
<tr style="border:none;background-color:rgb(255,255,255);font-size:12.8px;width:90%">
<td align="left" style="padding:48px 10px">
The response from the remote server was:<br>
<p style="font-family:monospace">
550 5.4.1 [<a href="mailto:jiwang@tilera.com" target="_blank">jiwang@tilera.com</a>]: Recipient address rejected: Access denied [<a href="http://VE1EUR03FT018.eop-EUR03.prod.protection.outlook.com" target="_blank">VE1EUR03FT018.eop-EUR03.prod.protection.outlook.com</a>]
</p>
</td>
</tr>
</tbody></table>
</div>
<br><br><br>---------- Forwarded message ----------<br>From: Roman Lebedev <<a href="mailto:lebedev.ri@gmail.com" target="_blank">lebedev.ri@gmail.com</a>><br>To: Jiong Wang <<a href="mailto:jiwang@tilera.com" target="_blank">jiwang@tilera.com</a>><br>Cc: <a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>Bcc: <br>Date: Thu, 28 Feb 2019 22:21:51 +0300<br>Subject: Re: [llvm] r355124 - bpf: improve dead Defs check for XADD<br>Test? (Was this reviewed somewhere?)<br>
<br>
<br>
On Thu, Feb 28, 2019 at 10:19 PM Jiong Wang via llvm-commits<br>
<<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>> wrote:<br>
><br>
> Author: jiwang<br>
> Date: Thu Feb 28 11:20:26 2019<br>
> New Revision: 355124<br>
><br>
> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=355124&view=rev" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project?rev=355124&view=rev</a><br>
> Log:<br>
> bpf: improve dead Defs check for XADD<br>
><br>
> BPF XADD semantics require all Defs of XADD are dead, meaning any result of<br>
> XADD insn is not used.<br>
><br>
> However, BPF backend hasn't enabled sub-register liveness track, so when<br>
> the source and destination operands of XADD are GPR32, there is no<br>
> sub-register dead info. If we rely on the generic<br>
> MachineInstr::allDefsAreDead, then we will raise false alarm on GPR32 Def.<br>
> This was fine as there was no sub-register code-gen support for XADD which<br>
> will be added by the next patch.<br>
><br>
> To support GPR32 Def, ideally we could just enable sub-registr liveness<br>
> track on BPF backend, then allDefsAreDead could work on GPR32 Def. This<br>
> requires implementing TargetSubtargetInfo::enableSubRegLiveness on BPF.<br>
><br>
> However, sub-register liveness tracking module inside LLVM is actually<br>
> designed for the situation where one register could be split into more<br>
> than one sub-registers for which case each sub-register could have their<br>
> own liveness and kill one of them doesn't kill others. So, tracking<br>
> liveness for each make sense.<br>
><br>
> For BPF, each 64-bit register could only have one 32-bit sub-register. This<br>
> is exactly the case which LLVM think brings no benefits for doing<br>
> sub-register tracking, because the live range of sub-register must always<br>
> equal to its parent register, therefore liveness tracking is disabled even<br>
> the back-end has implemented enableSubRegLiveness. The detailed information<br>
> is at r232695:<br>
><br>
> Author: Matthias Braun <<a href="mailto:matze@braunis.de" target="_blank">matze@braunis.de</a>><br>
> Date: Thu Mar 19 00:21:58 2015 +0000<br>
> Do not track subregister liveness when it brings no benefits<br>
><br>
> Hence, for BPF, we enhance MachineInstr::allDefsAreDead. Given the solo<br>
> sub-register always has the same liveness as its parent register, LLVM is<br>
> already attaching a implicit 64-bit register Def whenever the there is<br>
> a sub-register Def. The liveness of the implicit 64-bit Def is available.<br>
> For example, for "lock *(u32 *)(r0 + 4) += w9", the MachineOperand info<br>
> could be:<br>
><br>
> $w9 = XADDW32 killed $r0, 4, $w9(tied-def 0),<br>
> implicit killed $r9, implicit-def dead $r9<br>
><br>
> Even though w9 is not marked as Dead, the parent register r9 is marked as<br>
> Dead correctly, and it is safe to use such information or our purpose.<br>
><br>
> v1 -> v2:<br>
> - Simplified code logic inside hasLiveDefs. (Yonghong)<br>
><br>
> Acked-by: Yonghong Song <<a href="mailto:yhs@fb.com" target="_blank">yhs@fb.com</a>><br>
> Signed-off-by: Jiong Wang <<a href="mailto:jiong.wang@netronome.com" target="_blank">jiong.wang@netronome.com</a>><br>
><br>
><br>
> Modified:<br>
> llvm/trunk/lib/Target/BPF/BPFMIChecking.cpp<br>
><br>
> Modified: llvm/trunk/lib/Target/BPF/BPFMIChecking.cpp<br>
> URL: <a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/BPF/BPFMIChecking.cpp?rev=355124&r1=355123&r2=355124&view=diff" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/BPF/BPFMIChecking.cpp?rev=355124&r1=355123&r2=355124&view=diff</a><br>
> ==============================================================================<br>
> --- llvm/trunk/lib/Target/BPF/BPFMIChecking.cpp (original)<br>
> +++ llvm/trunk/lib/Target/BPF/BPFMIChecking.cpp Thu Feb 28 11:20:26 2019<br>
> @@ -61,6 +61,97 @@ void BPFMIPreEmitChecking::initialize(Ma<br>
> LLVM_DEBUG(dbgs() << "*** BPF PreEmit checking pass ***\n\n");<br>
> }<br>
><br>
> +// Make sure all Defs of XADD are dead, meaning any result of XADD insn is not<br>
> +// used.<br>
> +//<br>
> +// NOTE: BPF backend hasn't enabled sub-register liveness track, so when the<br>
> +// source and destination operands of XADD are GPR32, there is no sub-register<br>
> +// dead info. If we rely on the generic MachineInstr::allDefsAreDead, then we<br>
> +// will raise false alarm on GPR32 Def.<br>
> +//<br>
> +// To support GPR32 Def, ideally we could just enable sub-registr liveness track<br>
> +// on BPF backend, then allDefsAreDead could work on GPR32 Def. This requires<br>
> +// implementing TargetSubtargetInfo::enableSubRegLiveness on BPF.<br>
> +//<br>
> +// However, sub-registe<br>
----- Message truncated -----</blockquote></div></div>