What is the type of imm16 in builtin-func?
hi all
I write a pattern like this:
(define_insn "extrv4di"
[(set (match_operand:V4DI 0 "register_operand" "=Z")
(unspec:V4DI
[(match_operand:V4DI 1 "register_operand" "Z")
(match_operand:SI 2 "immediate_operand" "")]
UNSPEC_EXTR))]
"TARGET_VECTORS"
"extrd\t%0,%1,%2"
[(set_attr "type" "vadd")])
and the the code in mips.c:
#define CODE_FOR_extrd CODE_FOR_extrv4di
XX_BUILTIN (extrd, MIPS_V4DI_FTYPE_V4DI_INT),
define a macro in mips.md:
(UNSPEC_EXTR 821)
the xx.h:
__extension__ static __inline int64x4_t __attribute__ ((__always_inline__))
extrd (int64x4_t s, const int i)
{
return __builtin_extrd (s, i);
}
When I write a testcase like:
int64x4_t vec_vpextrd (int64x4_t s, const int t)
{
int64x4_t r;
r = vpextrd (s, t);
return r;
}
I get a error:
/opt/cross-tools/bin/../lib/gcc/mips64el-unknown-linux-gnu/4.5.1/include/xx.h:1535:31:
error: invalid argument to built-in function
What should I do? What's the type of imm8/imm16 in builtin-func?
Thanks.
--Liu
[viewvc]: Bad legibility
In viewvc's colored diff views, there is no CSS class defined for changed lines One example: http://gcc.gnu.org/viewcvs/trunk/gcc/config/avr/libgcc.S?r1=172384&r2=172383&pathrev=172384&diff_format=h The "removed" lines have a red background and can be seen easily. But the "changed" lines have just a slight variation in font face and it's hard to find all changed lines. The "changed" lines refer to a CSS class "vc_diff_change" which is defined nowhere: http://gcc.gnu.org/viewvc-static/styles.css doesn't define that class. Moreover, the red lines use a fixed-size font whereas other source lines use a variable-width font which make it hard to distinguish O/0 resp. I/l/1/|. IMO a fixed-width, same-face font for all source lines is preferable, and the changed lines could be better seen if they had a distinct background color like, say, yellow. Johann
Re: [viewvc]: Bad legibility
On Mon, 25 Apr 2011, Georg-Johann Lay wrote:
> In viewvc's colored diff views, there is no CSS class defined for
> changed lines
>
> One example:
>
> http://gcc.gnu.org/viewcvs/trunk/gcc/config/avr/libgcc.S?r1=172384&r2=172383&pathrev=172384&diff_format=h
>
> The "removed" lines have a red background and can be seen easily.
> But the "changed" lines have just a slight variation in font face and it's
> hard to find all changed lines.
>
> The "changed" lines refer to a CSS class "vc_diff_change" which is
> defined nowhere: http://gcc.gnu.org/viewvc-static/styles.css doesn't
> define that class.
>
> Moreover, the red lines use a fixed-size font whereas other source lines use a
> variable-width font which make it hard to distinguish O/0 resp. I/l/1/|.
>
> IMO a fixed-width, same-face font for all source lines is preferable,
> and the changed lines could be better seen if they had a distinct
> background color like, say, yellow.
Interesting. I addressed this by patching /var/www/viewvc/styles.css
as follows, though I am really wondering why this was (obviously) broken
to begin with.
overseers, do you have any idea?
Gerald
--- styles.css.orig 2010-03-31 20:59:31.0 +
+++ styles.css 2011-04-25 12:24:15.0 +
@@ -282,17 +282,22 @@
/*** Diff Styles ***/
.vc_diff_plusminus { width: 1em; }
-.vc_diff_remove, .vc_diff_add, .vc_diff_changes1, .vc_diff_changes2 {
+.vc_diff_remove, .vc_diff_add, .vc_diff_changes1, .vc_diff_changes2,
+.vc_diff_change {
font-family: monospace;
+ font-size: smaller;
white-space: pre;
}
.vc_diff_remove { background: rgb(100%,60%,60%); }
.vc_diff_add { background: rgb(60%,100%,60%); }
.vc_diff_changes1 { background: rgb(100%,100%,70%); color: rgb(50%,50%,50%);
text-decoration: line-through; }
.vc_diff_changes2 { background: rgb(100%,100%,0%); }
+.vc_diff_change { background: rgb(100%,100%,0%); }
+
.vc_diff_nochange, .vc_diff_binary, .vc_diff_error {
- font-family: sans-serif;
+ font-family: monospace;
font-size: smaller;
+ white-space: pre;
}
/*** Intraline Diff Styles ***/
adjacent bitfields optimization
Hi All,
For the fllowing code:
typedef struct {
int f1:1;
int f2:1;
int f3:1;
int f4:29;
} t1;
typedef struct {
int f1:1;
int f2:1;
int f3:30;
} t2;
t1 s1;
t2 s2;
void func1(void)
{
s1.f1 = s2.f1;
s1.f2 = s2.f2;
}
we get (x86_64 target):
movzbl s2(%rip), %edx
movzbl s1(%rip), %eax
movl %edx, %ecx
andl $-4, %eax
andl $2, %edx
andl $1, %ecx
orl %ecx, %eax
orl %edx, %eax
movb %al, s1(%rip)
ret
Could gcc optimize two or more operations in adjacent bitfields into one
operation ?
regards,
Alex R. Prado
Re: Traversing typedef hierarchy in C/C++ tree
Hi Dodji,
Dodji Seketeli writes:
> Boris Kolpackov a =C3=A9crit:
>
> > struct s {};
> >
> > typedef s s_t;
> > typedef s_t my_s_t;
> >
> > my_s_t x;
> >
>
> In G++, let's say that the tree node representing my_s_t is t. Then,
> DECL_ORIGINAL_TYPE (TYPE_NAME (t)) points to the tree node of s_t. You
> can walk the relationship "t is a typedef of foo" like that.
Yes, that's exactly what I was looking for. Thanks for the pointer!
While it works well for the above case, a template argument in the
path seems to break things. For example:
template
struct wrap
{
typedef T w_s;
};
typedef wrap::w_s w_s_t;
Now if I traverse from w_s_t using DECL_ORIGINAL_TYPE I get:
w_s_t->w_s->s
Instead of:
w_s_t->w_s->my_s_t->s_t->s
Do you know if there is a way to get this information?
Thanks,
Boris
Re: What is the type of imm16 in builtin-func?
Liu writes: > I get a error: > /opt/cross-tools/bin/../lib/gcc/mips64el-unknown-linux-gnu/4.5.1/include/xx.h:1535:31: > error: invalid argument to built-in function That is an error from the MIPS backend. In this case it seems to mean that the mode for the type int64x4_t does not match the mode for the insn in the .md file. I don't know where int64x4_t is defined, so I don't know what its mode is. It looks like you want the mode to be V4DImode; is it? Ian
Re: adjacent bitfields optimization
cirrus75 writes:
> For the fllowing code:
>
> typedef struct {
> int f1:1;
> int f2:1;
> int f3:1;
> int f4:29;
> } t1;
>
> typedef struct {
> int f1:1;
> int f2:1;
> int f3:30;
> } t2;
>
> t1 s1;
> t2 s2;
>
> void func1(void)
> {
> s1.f1 = s2.f1;
> s1.f2 = s2.f2;
> }
>
> we get (x86_64 target):
>
> movzbl s2(%rip), %edx
> movzbl s1(%rip), %eax
> movl %edx, %ecx
> andl $-4, %eax
> andl $2, %edx
> andl $1, %ecx
> orl %ecx, %eax
> orl %edx, %eax
> movb %al, s1(%rip)
> ret
>
>
> Could gcc optimize two or more operations in adjacent bitfields into one
> operation ?
This question looks more appropriate for the mailing list
gcc-h...@gcc.gnu.org rather than the mailing list gcc@gcc.gnu.org.
I agree that this looks like suboptimal code. Please consider filing a
missed-optimization bug report. See http://gcc.gnu.org/bugs/ . Thanks.
Ian
Re: Traversing typedef hierarchy in C/C++ tree
Hello Boris,
Boris Kolpackov a écrit:
> Hi Dodji,
>
> Dodji Seketeli writes:
>
>> Boris Kolpackov a =C3=A9crit:
>>
>> > struct s {};
>> >
>> > typedef s s_t;
>> > typedef s_t my_s_t;
>> >
>> > my_s_t x;
>> >
>>
>> In G++, let's say that the tree node representing my_s_t is t. Then,
>> DECL_ORIGINAL_TYPE (TYPE_NAME (t)) points to the tree node of s_t. You
>> can walk the relationship "t is a typedef of foo" like that.
>
> Yes, that's exactly what I was looking for. Thanks for the pointer!
You are welcome.
>
> While it works well for the above case, a template argument in the
> path seems to break things. For example:
>
> template
> struct wrap
> {
> typedef T w_s;
> };
>
> typedef wrap::w_s w_s_t;
>
> Now if I traverse from w_s_t using DECL_ORIGINAL_TYPE I get:
>
> w_s_t->w_s->s
>
> Instead of:
>
> w_s_t->w_s->my_s_t->s_t->s
Ah. Indeed. We strip typedefs from template arguments because G++
keeps only one instance of each template specialization. So it chooses
to keep the "canonical" one. In other words wrap and wrap
ultimately representing the same specialization, G++ only construct one
of them. And it chooses to construct wrap because 's' is the
canonical type here and not "my_s_t". If did choose to keep "my_s_t",
error messages would refer to wrap even for cases where it
really is wrap that has actually been written by the user. That
would be confusing.
> Do you know if there is a way to get this information?
I don't know, sorry. I am afraid to say that in that particular case,
the information you are looking for is lost.
--
Dodji
Re: What is the type of imm16 in builtin-func?
On Tue, Apr 26, 2011 at 1:44 AM, Ian Lance Taylor wrote: > Liu writes: > >> I get a error: >> /opt/cross-tools/bin/../lib/gcc/mips64el-unknown-linux-gnu/4.5.1/include/xx.h:1535:31: >> error: invalid argument to built-in function > > That is an error from the MIPS backend. > > In this case it seems to mean that the mode for the type int64x4_t does > not match the mode for the insn in the .md file. I don't know where > int64x4_t is defined, so I don't know what its mode is. It looks like > you want the mode to be V4DImode; is it? > > Ian > Thank you, Ian. Yes, I want V4DImode and in the xx.md file I write match_operand:V4DI in this pattern. The type of int64x4_t is define in xx.h: typedef int64_t int64x4_t __attribute__((vector_size (32))); This type is OK in other builtin-funcs, only imm-operand-builtin-funcs get this error. So, I'm confused. --Liu
gcc and scientific computing
Hi, I am involved in a scientific computing podcast, http://inscight.org/ I was wondering if anyone from the GCC project would like to be a special guest on the show to talk about recent developments in GCC for scientific computing in C/C++. We could discuss, e.g., the graphite optimizations, link time optimization, C++Ox, ... Thanks, Matt
