On 7/9/24 21:36, Jeff Law wrote:
>> +;; TODO: isinf is a bit tricky as it require trimodal return
>> +;; 1 if 0x80, -1 if 0x1, 0 otherwise
[..]
>> + rtx tmp2 = gen_reg_rtx (word_mode);
>> + emit_insn (gen_ashldi3 (tmp2, rclass, GEN_INT (w)));
>> + emit_insn (gen_lshrdi3 (tmp2, tmp2
On 7/9/24 5:44 PM, Vineet Gupta wrote:
On 6/30/24 06:59, Jeff Law wrote:
+;; TODO: isinf is a bit tricky as it require trimodal return
+;; 1 if 0x80, -1 if 0x1, 0 otherwise
It shouldn't be terrible, but it's not trivial either.
bext t0, a0, 0
neg t0
bext t1, a0, 7
czero.nez res, t0, t
On Tue, 2024-07-09 at 16:33 -0700, Vineet Gupta wrote:
>
>
> On 7/9/24 16:23, Jeff Law wrote:
> >
> > On 7/9/24 5:08 PM, Vineet Gupta wrote:
> > > On 7/3/24 12:08, Xi Ruoyao wrote:
> > > > On Fri, 2024-06-28 at 17:53 -0700, Vineet Gupta wrote:
> > > > > I was also hoping to get __builtin_inf() d
On 6/30/24 06:59, Jeff Law wrote:
+;; TODO: isinf is a bit tricky as it require trimodal return
+;; 1 if 0x80, -1 if 0x1, 0 otherwise
>>> It shouldn't be terrible, but it's not trivial either.
>>>
>>> bext t0, a0, 0
>>> neg t0
>>> bext t1, a0, 7
>>> czero.nez res, t0, t1
>>> snez t1
On 7/9/24 16:23, Jeff Law wrote:
>
> On 7/9/24 5:08 PM, Vineet Gupta wrote:
>> On 7/3/24 12:08, Xi Ruoyao wrote:
>>> On Fri, 2024-06-28 at 17:53 -0700, Vineet Gupta wrote:
I was also hoping to get __builtin_inf() done but unforutnately it
requires little more rtl foo/bar to implement a
On 7/9/24 5:08 PM, Vineet Gupta wrote:
On 7/3/24 12:08, Xi Ruoyao wrote:
On Fri, 2024-06-28 at 17:53 -0700, Vineet Gupta wrote:
I was also hoping to get __builtin_inf() done but unforutnately it
requires little more rtl foo/bar to implement a tri-modal return.
Hmm do we really need to care
On 7/3/24 12:08, Xi Ruoyao wrote:
> On Fri, 2024-06-28 at 17:53 -0700, Vineet Gupta wrote:
>> I was also hoping to get __builtin_inf() done but unforutnately it
>> requires little more rtl foo/bar to implement a tri-modal return.
> Hmm do we really need to care the symbol? The generic __builtin_
On 7/1/24 06:42, Jeff Law wrote:
>>> This works because those expanders are allowed to use FAIL. Some
>>> expanders aren't allowed to do that (they're supposed to be documented
>>> appropriately in the internals manual).
>>>
>>> In the matching define_insns, you can use X and adjust their names.
>
On Fri, 2024-06-28 at 17:53 -0700, Vineet Gupta wrote:
> I was also hoping to get __builtin_inf() done but unforutnately it
> requires little more rtl foo/bar to implement a tri-modal return.
Hmm do we really need to care the symbol? The generic __builtin_isinf
does not care the symbol anyway: ht
On 6/30/24 6:46 PM, Vineet Gupta wrote:
On 6/30/24 06:59, Jeff Law wrote:
Any ideas on how I can keep this and then adjust rest of patterns.
Yea. Drop the "SImode" references from the RTL template of the
expander. Then you'll need to verify the modes in the C fragment that
generates cod
The problem should be fixed after my value range patches being accepted.
[PATCH-1v3] Value Range: Add range op for builtin isinf
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653096.html
[PATCH-2v4] Value Range: Add range op for builtin isfinite
https://gcc.gnu.org/pipermail/gcc-patches/2024-M
On 6/30/24 06:59, Jeff Law wrote:
>> Any ideas on how I can keep this and then adjust rest of patterns.
> Yea. Drop the "SImode" references from the RTL template of the
> expander. Then you'll need to verify the modes in the C fragment that
> generates code. You'd want to test the mode of
On 6/30/24 00:41, Xi Ruoyao wrote:
> On Fri, 2024-06-28 at 17:53 -0700, Vineet Gupta wrote:
>> + UNSPEC_ISFINITE
>> + UNSPEC_ISNORMAL
> You don't really need them. The RTL pattern of define_expand has no use
> when you expand it via C code and DONE.
>
> i.e. you can just code
>
> (define_expa
On 6/29/24 3:07 PM, Vineet Gupta wrote:
On 6/29/24 06:44, Jeff Law wrote:
+;; fclass instruction output bitmap
+;; 0 negative infinity
+;; 1 negative normal number.
+;; 2 negative subnormal number.
+;; 3 -0
+;; 4 +0
+;; 5 positive subnormal number.
+;; 6 positive normal number.
On Fri, 2024-06-28 at 17:53 -0700, Vineet Gupta wrote:
> + UNSPEC_ISFINITE
> + UNSPEC_ISNORMAL
You don't really need them. The RTL pattern of define_expand has no use
when you expand it via C code and DONE.
i.e. you can just code
(define_expand "isfinite2"
[(match_operand:SI 0 "register_o
On 6/29/24 06:44, Jeff Law wrote:
>> +;; fclass instruction output bitmap
>> +;; 0 negative infinity
>> +;; 1 negative normal number.
>> +;; 2 negative subnormal number.
>> +;; 3 -0
>> +;; 4 +0
>> +;; 5 positive subnormal number.
>> +;; 6 positive normal number.
>> +;; 7 positive in
On 6/28/24 6:53 PM, Vineet Gupta wrote:
Currently isfinite and isnormal use float compare instructions with fp
flags save/restored around them. Our perf team complained this could be
costly in uarch. RV Base ISA already has FCLASS.{d,s,h} instruction to
do FP compares w/o disturbing FP excepti
On 6/28/24 17:53, Vineet Gupta wrote:
> Currently isfinite and isnormal use float compare instructions with fp
> flags save/restored around them. Our perf team complained this could be
> costly in uarch. RV Base ISA already has FCLASS.{d,s,h} instruction to
> do FP compares w/o disturbing FP exc
+1 to any change that reduces the number of fflags accesses.
On Fri, Jun 28, 2024 at 5:54 PM Vineet Gupta wrote:
>
> Currently isfinite and isnormal use float compare instructions with fp
> flags save/restored around them. Our perf team complained this could be
> costly in uarch. RV Base ISA alr
Currently isfinite and isnormal use float compare instructions with fp
flags save/restored around them. Our perf team complained this could be
costly in uarch. RV Base ISA already has FCLASS.{d,s,h} instruction to
do FP compares w/o disturbing FP exception flags.
Coincidently, upstream ijust few d
20 matches
Mail list logo
