Hi Tejas,
[ Please do not top-post. ]
On Thu, Aug 22, 2019 at 09:09:37AM +0530, Tejas Joshi wrote:
> Yes, I tried basically every combination I could think of, just not
> with the "isa attr". Now, I have the following code and it is still
> seems not to be working. Am I missing any options to pas
> This does almost exactly the same as what the proposed float_narrow
> would do. Instead, write it as
>
> (define_insn "add_truncdfsf3"
> [(set (match_operand:SF 0 "gpc_reg_operand" "=,wa")
> (unspec:SF [(match_operand:DF 1 "gpc_reg_operand" "%,wa")
> (match_operand:
I'm trying to do some analysis code for an optimization
that involves my code looking at all the declarations and
types there of during the link time optimizations.
Note, doing this for the local variables seems to be trivial
because of FOR_EACH_LOCAL_DECL and there are also
obvious ways of gettin
On Wed, Aug 21, 2019 at 01:28:52PM -0500, Segher Boessenkool wrote:
> (define_insn "add_truncdfsf3"
> [(set (match_operand:SF 0 "gpc_reg_operand" "=,wa")
> (unspec:SF [(match_operand:DF 1 "gpc_reg_operand" "%,wa")
> (match_operand:DF 2 "gpc_reg_operand" ",wa")]
>
Hi Tejas,
On Wed, Aug 21, 2019 at 10:56:51PM +0530, Tejas Joshi wrote:
> I have the following code which uses unspec but I am really missing
> something here. Does unspec not work encapsulating plus? Or I have
> some more places to make changes to?
>
> (define_insn "add_truncdfsf3"
> [(set (mat
On Wed, 21 Aug 2019 at 17:50, Paul Koning wrote:
>
>
>
> > On Aug 21, 2019, at 10:57 AM, Alexander Monakov wrote:
> >
> > On Wed, 21 Aug 2019, Paul Koning wrote:
> >
> >> I agree, but if the new approach generates a warning for code that was
> >> written
> >> to the old rules, that would be unfo
Hello.
I have the following code which uses unspec but I am really missing
something here. Does unspec not work encapsulating plus? Or I have
some more places to make changes to?
(define_insn "add_truncdfsf3"
[(set (match_operand:SF 0 "gpc_reg_operand" "=,wa")
(unspec:SF
[(plus:DF
> On Aug 21, 2019, at 10:57 AM, Alexander Monakov wrote:
>
> On Wed, 21 Aug 2019, Paul Koning wrote:
>
>> I agree, but if the new approach generates a warning for code that was
>> written
>> to the old rules, that would be unfortunate.
>
> FWIW I don't know which GCC versions accepted 'pack
On Wed, 21 Aug 2019, Paul Koning wrote:
> I agree, but if the new approach generates a warning for code that was written
> to the old rules, that would be unfortunate.
FWIW I don't know which GCC versions accepted 'packed' on a scalar type.
Already in 2006 GCC 3.4 would issue a warning:
$ echo '
> On Aug 21, 2019, at 10:28 AM, Alexander Monakov wrote:
>
> On Tue, 20 Aug 2019, "Markus Fröschle" wrote:
>
>> Thank you (and others) for your answers. Now I'm just as smart as before,
>> however.
>>
>> Is it a supported, documented, 'long term' feature we can rely on or not?
>>
>> If yes
On Tue, 20 Aug 2019, "Markus Fröschle" wrote:
> Thank you (and others) for your answers. Now I'm just as smart as before,
> however.
>
> Is it a supported, documented, 'long term' feature we can rely on or not?
>
> If yes, I would expect it to be properly documented. If not, never mind.
I thin
> On 20 Aug 2019, at 17:15, Florian Weimer wrote:
>
> * Richard Biener:
>
>> On August 20, 2019 5:19:33 PM GMT+02:00, Nathan Sidwell
>> wrote:
>>> On 7/26/19 6:03 AM, Iain Sandoe wrote:
Hello Sebastian,
> On 26 Jul 2019, at 10:19, Florian Weimer wrote:
>>>
> C++ coroutin
12 matches
Mail list logo
