Truncating df to sf (and typo in code)
Hi, I have been looking at the fp-bit code and noticed: /* numeric parameters */ /* F_D_BITOFF is the number of bits offset between the MSB of the mantissa of a float and of a double. Assumes there are only two float types. (double::FRAC_BITS+double::NGARDS-(float::FRAC_BITS-float::NGARDS)) */ #define F_D_BITOFF (52+8-(23+7)) I would guess the comment has a typo and should be (double::FRAC_BITS+double::NGARDS-(float::FRAC_BITS+float::NGARDS)) instead. In my port I am having some trouble with the truncation from df to sf. I wonder if there's any doc reference upon which the code was based to do the truncation. I can't really find anything and even though the code is not hard I am still missing something. Cheers, -- PMatos
Re: Truncating df to sf (and typo in code)
On Wed, 13 Apr 2011, Paulo J. Matos wrote: > I have been looking at the fp-bit code and noticed: > In my port I am having some trouble with the truncation from df to sf. Unless your port is outside the scope of what soft-fp supports (for example, soft-fp probably won't work for systems with 16-bit int, and such systems may also be too space-constrained for the soft-fp code) I'd advise using soft-fp instead of fp-bit for a new port since it's significantly faster (although the code is a bit larger). (For that matter, I encourage converting existing ports from fp-bit to soft-fp for the same reason - though you may wish to benchmark for your target to confirm you get similar speedups to those seen on Power Architecture processors.) > I wonder if there's any doc reference upon which the code was based to do the > truncation. I can't really find anything and even though the code is not hard > I am still missing something. The soft-fp code is, however, somewhat harder to understand than the less highly optimized fp-bit code. -- Joseph S. Myers jos...@codesourcery.com
Announce: MELT plugin (0.7) release candidate 2 for GCC 4.6
Hello All,
I am announcing the release candidate #2 of the MELT plugin (v0.7),
replacing the rc1 of http://gcc.gnu.org/ml/gcc/2011-04/msg00213.html
You can download a gzipped tar source ball of MELT 0.7 as plugin for GCC 4.6
from http://gcc-melt.org/melt-0.7rc2-plugin-for-gcc-4.6.tgz
It is a gzip-ed tar archive of 3192100 bytes of md5sum
519a235bbdb226f4a358ee6a68c1e46f (april 13th 2011). It is extracted from
MELT branch svn revision 172371.
You need a gcc 4.6 with plugins i(and cloog or graphite) enabled.
Improvements from the previous rc1 include fixes in the build script.
Comments are welcome. If you have been able to build the MELT plugin so
released, please tell me by private email. Bugs reports (including build
failure of the MELT plugin) are also welcome.
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Using intrinsic functions to extend the isa
Hi,
I'm currently try to add intrinsic functions to extend the x86 instruction
set. Encountered a problem when the intrinsic function's return value
is void, where the asm will not generate in this case.
the intrinsic function looks like:
extern void
__attribute__((__gnu_inline__, __always_inline__, __artificial__))
__TTest (unsigned int __C, unsigned int __V, unsigned int offset)
{
__builtin_ia32_ttest (__C, __V, offset);
}
and the corresponding md part is:
(define_expand "dta_ttest"
[(set (match_operand:SI 1 "register_operand" "")
(unspec:SI
[(match_operand:SI 2 "register_operand" "")
(match_operand:SI 3 "register_operand" "")]
UNSPEC_TSTORE))]
"TARGET_DTA"
"(void) operand0;")
(define_insn "*dta_ttest"
[(set (match_operand:SI 0 "register_operand" "=r")
(unspec:SI
[(match_operand:SI 1 "register_operand" "0")
(match_operand:SI 2 "register_operand" "")]
UNSPEC_TSTORE))]
"TARGET_DTA"
"ttest\t%0 %1 %2"
[(set_attr "length" "3")
(set_attr "mode" "SI")])
The asm will not generate "ttest\t %0 %1 %2" in this case, but if I
change the return value from void to uint, it will generate the correct
code.
I'm wondering how could I generate asm code for the intrinsic functions
with return value of void.
Thanks,
Feng
Re: Using intrinsic functions to extend the isa
Feng LI writes:
> I'm currently try to add intrinsic functions to extend the x86 instruction
> set. Encountered a problem when the intrinsic function's return value
> is void, where the asm will not generate in this case.
>
> the intrinsic function looks like:
>
> extern void
> __attribute__((__gnu_inline__, __always_inline__, __artificial__))
> __TTest (unsigned int __C, unsigned int __V, unsigned int offset)
> {
> __builtin_ia32_ttest (__C, __V, offset);
> }
>
> and the corresponding md part is:
>
> (define_expand "dta_ttest"
> [(set (match_operand:SI 1 "register_operand" "")
> (unspec:SI
> [(match_operand:SI 2 "register_operand" "")
> (match_operand:SI 3 "register_operand" "")]
> UNSPEC_TSTORE))]
> "TARGET_DTA"
> "(void) operand0;")
>
> (define_insn "*dta_ttest"
> [(set (match_operand:SI 0 "register_operand" "=r")
> (unspec:SI
> [(match_operand:SI 1 "register_operand" "0")
> (match_operand:SI 2 "register_operand" "")]
> UNSPEC_TSTORE))]
> "TARGET_DTA"
> "ttest\t%0 %1 %2"
> [(set_attr "length" "3")
>(set_attr "mode" "SI")])
>
>
> The asm will not generate "ttest\t %0 %1 %2" in this case, but if I
> change the return value from void to uint, it will generate the correct
> code.
>
> I'm wondering how could I generate asm code for the intrinsic functions
> with return value of void.
If the intrinsic has no return value, then you need to use
unspec_volatile. Otherwise the compiler will see that you have an
instruction which doesn't do anything, and will remove it.
But if the instrinsic returns void, I don't understand why you are
setting an operand in the insn. What does it get set to?
Ian
Re: Using intrinsic functions to extend the isa
Hi Ian,
Thanks for your comments.
On Wed, Apr 13, 2011 at 5:02 PM, Ian Lance Taylor wrote:
> Feng LI writes:
>
>> I'm currently try to add intrinsic functions to extend the x86 instruction
>> set. Encountered a problem when the intrinsic function's return value
>> is void, where the asm will not generate in this case.
>>
>> the intrinsic function looks like:
>>
>> extern void
>> __attribute__((__gnu_inline__, __always_inline__, __artificial__))
>> __TTest (unsigned int __C, unsigned int __V, unsigned int offset)
>> {
>> __builtin_ia32_ttest (__C, __V, offset);
>> }
>>
>> and the corresponding md part is:
>>
>> (define_expand "dta_ttest"
>> [(set (match_operand:SI 1 "register_operand" "")
>> (unspec:SI
>> [(match_operand:SI 2 "register_operand" "")
>> (match_operand:SI 3 "register_operand" "")]
>> UNSPEC_TSTORE))]
>> "TARGET_DTA"
>> "(void) operand0;")
>>
>> (define_insn "*dta_ttest"
>> [(set (match_operand:SI 0 "register_operand" "=r")
>> (unspec:SI
>> [(match_operand:SI 1 "register_operand" "0")
>> (match_operand:SI 2 "register_operand" "")]
>> UNSPEC_TSTORE))]
>> "TARGET_DTA"
>> "ttest\t%0 %1 %2"
>> [(set_attr "length" "3")
>> (set_attr "mode" "SI")])
>>
>>
>> The asm will not generate "ttest\t %0 %1 %2" in this case, but if I
>> change the return value from void to uint, it will generate the correct
>> code.
>>
>> I'm wondering how could I generate asm code for the intrinsic functions
>> with return value of void.
>
> If the intrinsic has no return value, then you need to use
> unspec_volatile. Otherwise the compiler will see that you have an
> instruction which doesn't do anything, and will remove it.
>
> But if the instrinsic returns void, I don't understand why you are
> setting an operand in the insn. What does it get set to?
I tried the version with return value to see if it works at the beginning
and forgot to change it back...
I use unspec_volatile for a function with void arguments and
void return value for some initialization work. But it didn't generate
code in this case. I think probably I need to add more restrictions
some where but I don't know why and how. The code looks like:
extern __inline void __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
__TEnd (void)
{
__builtin_ia32_tend ();
}
(define_expand "dta_tend"
[(unspec_volatile [(const_int 0)] UNSPEC_TEND)]
""
"")
(define_insn "*dta_tend"
[(unspec_volatile [(const_int 0)] UNSPEC_TEND)]
""
"tend"
[(set_attr "length" "3")
(set_attr "mode" "none")])
Thanks,
Feng
>
> Ian
>
Re: Using intrinsic functions to extend the isa
Feng LI writes:
> I use unspec_volatile for a function with void arguments and
> void return value for some initialization work. But it didn't generate
> code in this case. I think probably I need to add more restrictions
> some where but I don't know why and how. The code looks like:
>
> extern __inline void __attribute__((__gnu_inline__, __always_inline__,
> __artificial__))
> __TEnd (void)
> {
> __builtin_ia32_tend ();
> }
>
> (define_expand "dta_tend"
> [(unspec_volatile [(const_int 0)] UNSPEC_TEND)]
> ""
> "")
>
> (define_insn "*dta_tend"
> [(unspec_volatile [(const_int 0)] UNSPEC_TEND)]
> ""
> "tend"
> [(set_attr "length" "3")
>(set_attr "mode" "none")])
In the RTL dumps generated by -da, where does the insn appear and where
does it disappear?
Ian
Re: Using intrinsic functions to extend the isa
On Wed, Apr 13, 2011 at 5:32 PM, Ian Lance Taylor wrote:
> Feng LI writes:
>
>> I use unspec_volatile for a function with void arguments and
>> void return value for some initialization work. But it didn't generate
>> code in this case. I think probably I need to add more restrictions
>> some where but I don't know why and how. The code looks like:
>>
>> extern __inline void __attribute__((__gnu_inline__, __always_inline__,
>> __artificial__))
>> __TEnd (void)
>> {
>> __builtin_ia32_tend ();
>> }
>>
>> (define_expand "dta_tend"
>> [(unspec_volatile [(const_int 0)] UNSPEC_TEND)]
>> ""
>> "")
>>
>> (define_insn "*dta_tend"
>> [(unspec_volatile [(const_int 0)] UNSPEC_TEND)]
>> ""
>> "tend"
>> [(set_attr "length" "3")
>> (set_attr "mode" "none")])
>
> In the RTL dumps generated by -da, where does the insn appear and where
> does it disappear?
Do you have any const or pure attributes on the tend builtin?
Richard.
> Ian
>
Re: Using intrinsic functions to extend the isa
On Wed, Apr 13, 2011 at 5:32 PM, Ian Lance Taylor wrote:
> Feng LI writes:
>
>> I use unspec_volatile for a function with void arguments and
>> void return value for some initialization work. But it didn't generate
>> code in this case. I think probably I need to add more restrictions
>> some where but I don't know why and how. The code looks like:
>>
>> extern __inline void __attribute__((__gnu_inline__, __always_inline__,
>> __artificial__))
>> __TEnd (void)
>> {
>> __builtin_ia32_tend ();
>> }
>>
>> (define_expand "dta_tend"
>> [(unspec_volatile [(const_int 0)] UNSPEC_TEND)]
>> ""
>> "")
>>
>> (define_insn "*dta_tend"
>> [(unspec_volatile [(const_int 0)] UNSPEC_TEND)]
>> ""
>> "tend"
>> [(set_attr "length" "3")
>> (set_attr "mode" "none")])
>
> In the RTL dumps generated by -da, where does the insn appear and where
> does it disappear?
It seems that it disappear at the ffork.c.143r.expand at the very beginning.
I suppose there should be some thing like
(call_insn ) generated for __builtin_ia32_tend (); But there isn't.
instead, it generated:
;; Generating RTL for gimple basic block 2
;; __builtin_ia32_tend ();
(nil)
Feng
>
> Ian
>
Re: Using intrinsic functions to extend the isa
On Wed, Apr 13, 2011 at 5:45 PM, Feng LI wrote:
> On Wed, Apr 13, 2011 at 5:32 PM, Ian Lance Taylor wrote:
>> Feng LI writes:
>>
>>> I use unspec_volatile for a function with void arguments and
>>> void return value for some initialization work. But it didn't generate
>>> code in this case. I think probably I need to add more restrictions
>>> some where but I don't know why and how. The code looks like:
>>>
>>> extern __inline void __attribute__((__gnu_inline__, __always_inline__,
>>> __artificial__))
>>> __TEnd (void)
>>> {
>>> __builtin_ia32_tend ();
>>> }
>>>
>>> (define_expand "dta_tend"
>>> [(unspec_volatile [(const_int 0)] UNSPEC_TEND)]
>>> ""
>>> "")
>>>
>>> (define_insn "*dta_tend"
>>> [(unspec_volatile [(const_int 0)] UNSPEC_TEND)]
>>> ""
>>> "tend"
>>> [(set_attr "length" "3")
>>> (set_attr "mode" "none")])
>>
>> In the RTL dumps generated by -da, where does the insn appear and where
>> does it disappear?
>
> It seems that it disappear at the ffork.c.143r.expand at the very beginning.
> I suppose there should be some thing like
> (call_insn ) generated for __builtin_ia32_tend (); But there isn't.
> instead, it generated:
>
> ;; Generating RTL for gimple basic block 2
> ;; __builtin_ia32_tend ();
> (nil)
You need to expand builtins yourself, a "named" expander doesn't do
that for you.
Richard.
> Feng
>>
>> Ian
>>
>
Re: Using intrinsic functions to extend the isa
On Wed, Apr 13, 2011 at 5:48 PM, Richard Guenther
wrote:
> On Wed, Apr 13, 2011 at 5:45 PM, Feng LI wrote:
>> On Wed, Apr 13, 2011 at 5:32 PM, Ian Lance Taylor wrote:
>>> Feng LI writes:
>>>
I use unspec_volatile for a function with void arguments and
void return value for some initialization work. But it didn't generate
code in this case. I think probably I need to add more restrictions
some where but I don't know why and how. The code looks like:
extern __inline void __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
__TEnd (void)
{
__builtin_ia32_tend ();
}
(define_expand "dta_tend"
[(unspec_volatile [(const_int 0)] UNSPEC_TEND)]
""
"")
(define_insn "*dta_tend"
[(unspec_volatile [(const_int 0)] UNSPEC_TEND)]
""
"tend"
[(set_attr "length" "3")
(set_attr "mode" "none")])
>>>
>>> In the RTL dumps generated by -da, where does the insn appear and where
>>> does it disappear?
>>
>> It seems that it disappear at the ffork.c.143r.expand at the very beginning.
>> I suppose there should be some thing like
>> (call_insn ) generated for __builtin_ia32_tend (); But there isn't.
>> instead, it generated:
>>
>> ;; Generating RTL for gimple basic block 2
>> ;; __builtin_ia32_tend ();
>> (nil)
>
> You need to expand builtins yourself, a "named" expander doesn't do
> that for you.
I'm not sure I understand this, I use define_expand to expand
the builtin function to RTX, and then define_insn * to match the
RTX and generate code. It seems it didn't generate the asm code.
> Do you have any const or pure attributes on the tend builtin?
Do you mean (set_attr "" "") in the define_insn?
Feng
>
> Richard.
>
>> Feng
>>>
>>> Ian
>>>
>>
>
Added myself to MAINTAINERS
Added myself to MAINTAINERS. Please update your MAINTAINERS file. Johann Index: ChangeLog === --- ChangeLog (Revision 172381) +++ ChangeLog (Revision 172382) @@ -1,3 +1,7 @@ +2011-04-13 Georg-Johann Lay + + * MAINTAINERS (Write After Approval): Add myself. + 2011-04-12 Yufeng Zhang * MAINTAINERS (Write After Approval): Add myself. Index: MAINTAINERS === --- MAINTAINERS (Revision 172381) +++ MAINTAINERS (Revision 172382) @@ -407,6 +407,7 @@ Rask Ingemann Lambertsenccc94453@vip. Asher Langton langt...@llnl.gov Chris Lattner sa...@nondot.org Terry Laurenzo tlaure...@gmail.com +Georg-Johann Lay a...@gjlay.de Marc Lehmann p...@goof.com James Lemkejwle...@juniper.net Kriang Lerdsuwanakij lerds...@users.sourceforge.net
Re: Using intrinsic functions to extend the isa
On 04/13/2011 09:05 AM, Feng LI wrote: >> You need to expand builtins yourself, a "named" expander doesn't do >> that for you. > > I'm not sure I understand this, I use define_expand to expand > the builtin function to RTX, and then define_insn * to match the > RTX and generate code. It seems it didn't generate the asm code. > >> Do you have any const or pure attributes on the tend builtin? > > Do you mean (set_attr "" "") in the define_insn? No, see ix86_expand_builtin and its many subroutines. r~
How to tell IRA to use misaligned DImode load?
Hi, On my target, SCmode is 4 byte aligned. But to load it into a register, it must be 8byte aligned. I can handle misaligned load in backend. But IRA generates misaligned load directly when SCmode is accessed as DImode. How can I tell IRA to use misaligned load for DImode? Thanks. -- H.J.
RE:How to tell IRA to use misaligned DImode load?
Hi, Do you mean you support unaligned access to any DImode regular type (int64_t) ? regards, Alex Prado "H.J. Lu" wrote: Hi, On my target, SCmode is 4 byte aligned. But to load it into a register, it must be 8byte aligned. I can handle misaligned load in backend. But IRA generates misaligned load directly when SCmode is accessed as DImode. How can I tell IRA to use misaligned load for DImode? Thanks. Hi, On my target, SCmode is 4 byte aligned. But to load it into a register, it must be 8byte aligned. I can handle misaligned load in backend. But IRA generates misaligned load directly when SCmode is accessed as DImode. How can I tell IRA to use misaligned load for DImode? Thanks.
Re: How to tell IRA to use misaligned DImode load?
On Wed, Apr 13, 2011 at 1:50 PM, cirrus75 wrote: > > Hi, > > Do you mean you support unaligned access to any DImode regular type > (int64_t) ? Real DImode support unaligned access. The problem is SCmode accessed via DImode. H.J. --- > regards, > Alex Prado > > > "H.J. Lu" wrote: > > Hi, > > On my target, SCmode is 4 byte aligned. But to load it into > a register, it must be 8byte aligned. I can handle misaligned > load in backend. But IRA generates misaligned load directly > when SCmode is accessed as DImode. How can I tell IRA to use > misaligned load for DImode? > > Thanks. > > > > > > Hi, > > On my target, SCmode is 4 byte aligned. But to load it into > a register, it must be 8byte aligned. I can handle misaligned > load in backend. But IRA generates misaligned load directly > when SCmode is accessed as DImode. How can I tell IRA to use > misaligned load for DImode? > > Thanks. > > > -- H.J.
Re: How to tell IRA to use misaligned DImode load?
On Wed, Apr 13, 2011 at 12:55 PM, H.J. Lu wrote: > Hi, > > On my target, SCmode is 4 byte aligned. But to load it into > a register, it must be 8byte aligned. I can handle misaligned > load in backend. But IRA generates misaligned load directly > when SCmode is accessed as DImode. How can I tell IRA to use > misaligned load for DImode? > Never mind. I figured it out. The backend should generate misaligned move at the first place. -- H.J.
