https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68991
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68991
--- Comment #19 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Tue Jan 5 20:19:16 2016
New Revision: 232088
URL: https://gcc.gnu.org/viewcvs?rev=232088&root=gcc&view=rev
Log:
Use vector_operand on SSE with 16b memory operand
Add vector_oper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68991
--- Comment #18 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Tue Jan 5 20:17:26 2016
New Revision: 232087
URL: https://gcc.gnu.org/viewcvs?rev=232087&root=gcc&view=rev
Log:
Add vector_memory_operand and "Bm" constraint
SSE vector arithmet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68991
--- Comment #17 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #15)
> IMNSHO you only want to touch patterns which don't have ssememalign
> attributes (== have it 0) and leave the others as is. Perhaps in the next
> step you can k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68991
--- Comment #16 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #15)
> (In reply to H.J. Lu from comment #11)
> > (In reply to Jakub Jelinek from comment #10)
> > > But why should the *mov_internal use Bm or vector_operand? It
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68991
--- Comment #15 from Jakub Jelinek ---
(In reply to H.J. Lu from comment #11)
> (In reply to Jakub Jelinek from comment #10)
> > But why should the *mov_internal use Bm or vector_operand? It
> > can/should handle both aligned and unaligned memor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68991
--- Comment #14 from H.J. Lu ---
(In reply to H.J. Lu from comment #13)
> > LRA is OK when Bm is properly defined as
> >
> > (define_memory_constraint "Bm"
> > "@internal Vector memory operand."
> > (match_operand 0 "vector_memory_operand")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68991
--- Comment #13 from H.J. Lu ---
(In reply to H.J. Lu from comment #12)
> (In reply to H.J. Lu from comment #9)
> > With Bm constraint on SSE *mov_internal, curr_insn_transform in
> > lra-constraints.c generates an extra
> >
> > (insn 354 353 32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68991
--- Comment #12 from H.J. Lu ---
(In reply to H.J. Lu from comment #9)
> With Bm constraint on SSE *mov_internal, curr_insn_transform in
> lra-constraints.c generates an extra
>
> (insn 354 353 323 8 (set (reg:V4SF 192)
> (reg:V4SF 202 [
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68991
--- Comment #11 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #10)
> But why should the *mov_internal use Bm or vector_operand? It
> can/should handle both aligned and unaligned memory operands.
Only for historical reason.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68991
--- Comment #10 from Jakub Jelinek ---
But why should the *mov_internal use Bm or vector_operand? It can/should
handle both aligned and unaligned memory operands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68991
H.J. Lu changed:
What|Removed |Added
CC||vmakarov at redhat dot com
--- Comment #9 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68991
--- Comment #8 from H.J. Lu ---
Another testcase:
[hjl@gnu-tools-1 pr68991]$ cat add.cc
typedef unsigned int size_type;
#define _GLIBCXX_BITSET_BITS_PER_WORD (__CHAR_BIT__ * __SIZEOF_INT__)
#define _GLIBCXX_BITSET_WORDS(__n) \
((__n) / _GLIB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68991
--- Comment #7 from H.J. Lu ---
[hjl@gnu-tools-1 pr68991]$ cat x.cc
#include
#include
typedef std::string StringRef;
template
class ArrayRef {
public:
typedef const T *iterator;
typedef size_t size_type;
private:
const T *Data;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68991
--- Comment #6 from H.J. Lu ---
I don't have a small testcase. I am testing
https://gcc.gnu.org/git/?p=gcc.git;a=patch;h=a93baf9afe49e059c9a7746608bdf7403fbaca42
to see if it fixes my problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68991
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68991
--- Comment #4 from H.J. Lu ---
Also
subreg:V4SI (reg:TI 247 [ MEM[(const struct bitset &)FeatureEntry_115 + 8] ])
0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68991
--- Comment #3 from H.J. Lu ---
Here is the misaligned source:
(subreg:V4SI (unspec:V16QI [
(mem:V16QI (subreg/s/v:SI (reg/v/f:DI 219 [ Bits ]) 0) [14
MEM[(long unsigned int *)Bits_12(D)]+0 S16 A32])
] UNSPEC_LOADU) 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68991
H.J. Lu changed:
What|Removed |Added
CC||ienkovich at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68991
H.J. Lu changed:
What|Removed |Added
Target|x32 |x86
Status|UNCONFIRMED
20 matches
Mail list logo
