diff options
| author | Jakub Jelinek <jakub@redhat.com> | 2022-12-02 11:08:45 +0100 |
|---|---|---|
| committer | Jakub Jelinek <jakub@redhat.com> | 2022-12-02 11:08:45 +0100 |
| commit | b3237a2c6847993f92218b65f96ece9831a8bfb0 (patch) | |
| tree | 6b3c507594612a44e0d1d7cbc1142393194c5ece /gcc/gcc.cc | |
| parent | f13305518558f20ef2d460a74eb29dad5fce1350 (diff) | |
| download | gcc-b3237a2c6847993f92218b65f96ece9831a8bfb0.zip gcc-b3237a2c6847993f92218b65f96ece9831a8bfb0.tar.gz gcc-b3237a2c6847993f92218b65f96ece9831a8bfb0.tar.bz2 | |
i386: Save/restore recog_data in ix86_vector_duplicate_value [PR106577]
On Tue, Aug 16, 2022 at 09:14:06AM +0100, Richard Sandiford via Gcc-patches wrote:
> IMO the correct low-effort fix is to save and restore recog_data
> in ix86_vector_duplicate_value. It's a relatively big copy,
> but the current code is pretty wasteful anyway (allocating at
> least a new SET and INSN for every query). Compared to the
> overhead of doing that, a copy to and from the stack shouldn't
> be too bad.
The following patch does that.
It isn't the first spot in the compiler that does that, not even the first
spot in the i386 backend.
In i386-expand.cc beyond these 2 recog_memoized calls there is one in
expand_vselect, but I think it is unlikely we'd run into these issues trying
to expand new permutations from splitters.
2022-12-02 Jakub Jelinek <jakub@redhat.com>
PR target/106577
* config/i386/i386-expand.cc (ix86_vector_duplicate_value): Save/restore
recog_data around recog_memoized calls.
* gcc.target/i386/pr106577.c: New test.
Diffstat (limited to 'gcc/gcc.cc')
0 files changed, 0 insertions, 0 deletions