All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiong Wang <jiong.wang@netronome.com>
To: Jiong Wang <jiong.wang@netronome.com>
Cc: Yonghong Song <yhs@fb.com>,
	"alexei.starovoitov\@gmail.com" <alexei.starovoitov@gmail.com>,
	"bpf\@vger.kernel.org" <bpf@vger.kernel.org>,
	"oss-drivers\@netronome.com" <oss-drivers@netronome.com>
Subject: Re: [LLVM PATCH] bpf: fix wrong truncation elimination when there is back-edge/loop
Date: Wed, 16 Oct 2019 16:33:15 +0100	[thread overview]
Message-ID: <4l08k8n8.fsf@cbtest28.netronome.com> (raw)
In-Reply-To: <1rvepbpe.fsf@cbtest28.netronome.com>


Jiong Wang writes:

> Yonghong Song writes:
>
>> On 10/12/19 12:18 AM, Jiong Wang wrote:
>>> Currently, BPF backend is doing truncation elimination. If one truncation
>>> is performed on a value defined by narrow loads, then it could be redundant
>>> given BPF loads zero extend the destination register implicitly.
>>> 
>>> When the definition of the truncated value is a merging value (PHI node)
>>> that could come from different code paths, then checks need to be done on
>>> all possible code paths.
>>> 
>>> Above described optimization was introduced as r306685, however it doesn't
>>> work when there is back-edge, for example when loop is used inside BPF
>>> code.
>>> 
>>> For example for the following code, a zero-extended value should be stored
>>> into b[i], but the "and reg, 0xffff" is wrongly eliminated which then
>>> generates corrupted data.
>>> 
>>> void cal1(unsigned short *a, unsigned long *b, unsigned int k)
>>> {
>>>    unsigned short e;
>>> 
>>>    e = *a;
>>>    for (unsigned int i = 0; i < k; i++) {
>>>      b[i] = e;
>>>      e = ~e;
>>>    }
>>> }
>>> 
>>> The reason is r306685 was trying to do the PHI node checks inside isel
>>> DAG2DAG phase, and the checks are done on MachineInstr. This is actually
>>> wrong, because MachineInstr is being built during isel phase and the
>>> associated information is not completed yet. A quick search shows none
>>> target other than BPF is access MachineInstr info during isel phase.
>>> 
>>> For an PHI node, when you reached it during isel phase, it may have all
>>> predecessors linked, but not successors. It seems successors are linked to
>>> PHI node only when doing SelectionDAGISel::FinishBasicBlock and this
>>> happens later than PreprocessISelDAG hook.
>>> 
>>> Previously, BPF program doesn't allow loop, there is probably the reason
>>> why this bug was not exposed.
>>> 
>>> This patch therefore fixes the bug by the following approach:
>>>   - The existing truncation elimination code and the associated
>>>     "load_to_vreg_" records are removed.
>>>   - Instead, implement truncation elimination using MachineSSA pass, this
>>>     is where all information are built, and keep the pass together with other
>>>     similar peephole optimizations inside BPFMIPeephole.cpp. Redundant move
>>>     elimination logic is updated accordingly.
>>>   - Unit testcase included + no compilation errors for kernel BPF selftest.
>>
>> Thanks for the fix. The code looks good. Just two minor comments.
>
> Thanks Yonghong. Your comments make sense to me, will fix them.
>
>> After the fix, could you directly push to the llvm repo?
>
> Sure will do.
>
> (And I will update my llvm account email first, should be quick, if it takes
> too long will come back to you for committing help)

Fix pushed after two minor comments addressed and re-unit-tested:

  https://github.com/llvm/llvm-project/commit/ec51851026a55e1cfc7f006f0e75f0a19acb32d3

Regards,
Jiong

  reply	other threads:[~2019-10-16 15:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-12  7:18 [LLVM PATCH] bpf: fix wrong truncation elimination when there is back-edge/loop Jiong Wang
2019-10-12 15:07 ` Yonghong Song
2019-10-15  2:41 ` Yonghong Song
2019-10-15 10:03   ` Jiong Wang
2019-10-16 15:33     ` Jiong Wang [this message]
2019-10-16 19:03       ` Yonghong Song

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4l08k8n8.fsf@cbtest28.netronome.com \
    --to=jiong.wang@netronome.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=oss-drivers@netronome.com \
    --cc=yhs@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.