From: Andrew MacLeod <amacleod@redhat.com>
To: Tamar Christina <Tamar.Christina@arm.com>,
Richard Biener <rguenther@suse.de>,
Richard Sandiford <Richard.Sandiford@arm.com>
Cc: Tamar Christina via Gcc-patches <gcc-patches@gcc.gnu.org>,
nd <nd@arm.com>, "jlaw@ventanamicro.com" <jlaw@ventanamicro.com>
Subject: Re: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask by using new optabs [PR108583]
Date: Wed, 22 Feb 2023 13:33:39 -0500 [thread overview]
Message-ID: <9378f3fb-0538-45fd-5066-1920de50e6c9@redhat.com> (raw)
In-Reply-To: <VI1PR08MB532560E4ED9CC6573DF22169FFAA9@VI1PR08MB5325.eurprd08.prod.outlook.com>
On 2/22/23 13:03, Tamar Christina wrote:
>> -----Original Message-----
>> From: Andrew MacLeod <amacleod@redhat.com>
>> Sent: Wednesday, February 22, 2023 4:42 PM
>> To: Tamar Christina <Tamar.Christina@arm.com>; Richard Biener
>> <rguenther@suse.de>; Richard Sandiford <Richard.Sandiford@arm.com>
>> Cc: Tamar Christina via Gcc-patches <gcc-patches@gcc.gnu.org>; nd
>> <nd@arm.com>; jlaw@ventanamicro.com
>> Subject: Re: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask
>> by using new optabs [PR108583]
>>
>>
>> On 2/15/23 13:42, Andrew MacLeod wrote:
>>> On 2/15/23 12:50, Andrew MacLeod wrote:
>>>> On 2/15/23 12:13, Tamar Christina wrote:
>>>>>> On 2/15/23 07:51, Tamar Christina wrote:
>>>> void
>>>> operator_plus::wi_fold (irange &r, tree type,
>>>> const wide_int &lh_lb, const wide_int &lh_ub,
>>>> const wide_int &rh_lb, const wide_int &rh_ub)
>>>> const {
>>>> wi::overflow_type ov_lb, ov_ub;
>>>> signop s = TYPE_SIGN (type);
>>>>
>>>> // Do whatever wideint magic is required to do this adds in higher
>>>> precision
>>>> wide_int new_lb = wi::add (lh_lb, rh_lb, s, &ov_lb);
>>>> wide_int new_ub = wi::add (lh_ub, rh_ub, s, &ov_ub);
>>>>
>>>> r = int_range<2> (type, new_lb, new_ub); }
>>>>
>>>>
>>>> The operator needs to be registered, I've attached the skeleton for
>>>> it. you should just have to finish implementing wi_fold().
>>>>
>>>> in theory :-)
>>>>
>>> You also mentioned earlier that some were tree codes, some were
>>> internal function calls? We have some initial support for built in
>>> functions, but I am not familiar with all the various forms they can
>>> take. We currently support CFN_ functions in
>>>
>>> gimple-range-op.cc, gimple_range_op_handler::maybe_builtin_call ()
>>>
>>> Basically this is part of a "gimple_range_op_handler" wrapper for
>>> range-ops which can provide a range-ops class for stmts that don't map
>>> to a binary or unary form.. such as built in functions.
>>>
>>> If you get to the point where you need this for a builtin function, I
>>> can help you through that too. Although someone may have to also help
>>> me through what differentiates the different kinds of internal
>>> function :-) I presume they are all similar in some way.
>>>
>>> Andrew
>>>
>> Oh yeah, and in case you haven't figured it out on your own, you'll have
>> to remove WIDEN_MULT_EXPR from the range-ops init table. This
>> non-standard mechanism only gets checked if there is no standard
>> range-op table entry for the tree code :-P
>>
> Hmm it looks like it'll work, but it keeps segfaulting in:
>
> bool
> range_op_handler::fold_range (vrange &r, tree type,
> const vrange &lh,
> const vrange &rh,
> relation_trio rel) const
> {
> gcc_checking_assert (m_valid);
> if (m_int)
> return m_int->fold_range (as_a <irange> (r), type,
> as_a <irange> (lh),
> as_a <irange> (rh), rel);
>
> while trying to call fold_range.
>
> But m_int is set to the right instance. Probably something I'm missing,
> I'll double check it all.
>
Hmm. whats your class operator_widen_mult* look like? what are you
inheriting from? Send me your patch and I'll have a look if you want.
this is somewhat new territory :-)
I cant imagine it being a linkage thing between the 2 files since the
operator is defined in another file and the address taken in this one?
that should work, but strange that cant make the call...
Andrew
next prev parent reply other threads:[~2023-02-22 18:33 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-09 17:16 Tamar Christina
2023-02-09 17:22 ` [PATCH 2/2]AArch64 Update div-bitmask to implement new optab instead of target hook [PR108583] Tamar Christina
2023-02-10 10:35 ` Tamar Christina
2023-02-10 14:10 ` Richard Sandiford
2023-02-10 10:34 ` [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask by using new optabs [PR108583] Tamar Christina
2023-02-10 13:13 ` Richard Biener
2023-02-10 13:36 ` Richard Sandiford
2023-02-10 13:52 ` Richard Biener
2023-02-10 14:13 ` Tamar Christina
2023-02-10 14:30 ` Richard Sandiford
2023-02-10 14:54 ` Tamar Christina
2023-02-27 11:09 ` Tamar Christina
2023-02-27 12:11 ` Richard Sandiford
2023-02-27 12:14 ` Tamar Christina
2023-02-27 21:33 ` Richard Sandiford
2023-02-27 22:10 ` Tamar Christina
2023-02-28 11:08 ` Richard Sandiford
2023-02-28 11:12 ` Tamar Christina
2023-02-28 12:03 ` Richard Sandiford
2023-03-01 11:30 ` Richard Biener
2023-02-10 15:56 ` Richard Sandiford
2023-02-10 16:09 ` Tamar Christina
2023-02-10 16:25 ` Richard Sandiford
2023-02-10 16:33 ` Tamar Christina
2023-02-10 16:57 ` Richard Sandiford
2023-02-10 17:01 ` Richard Sandiford
2023-02-10 17:14 ` Tamar Christina
2023-02-10 18:12 ` Richard Sandiford
2023-02-10 18:34 ` Richard Biener
2023-02-10 20:58 ` Andrew MacLeod
2023-02-13 9:54 ` Tamar Christina
2023-02-15 12:51 ` Tamar Christina
2023-02-15 16:05 ` Andrew MacLeod
2023-02-15 17:13 ` Tamar Christina
2023-02-15 17:50 ` Andrew MacLeod
2023-02-15 18:42 ` Andrew MacLeod
2023-02-22 12:51 ` Tamar Christina
2023-02-22 16:41 ` Andrew MacLeod
2023-02-22 18:03 ` Tamar Christina
2023-02-22 18:33 ` Andrew MacLeod [this message]
2023-02-23 8:36 ` Tamar Christina
2023-02-23 16:39 ` Andrew MacLeod
2023-02-23 16:56 ` Tamar Christina
2023-03-01 16:57 ` Andrew Carlotti
2023-03-01 18:16 ` Tamar Christina
2023-02-22 13:06 ` Tamar Christina
2023-02-22 15:19 ` Andrew MacLeod
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9378f3fb-0538-45fd-5066-1920de50e6c9@redhat.com \
--to=amacleod@redhat.com \
--cc=Richard.Sandiford@arm.com \
--cc=Tamar.Christina@arm.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jlaw@ventanamicro.com \
--cc=nd@arm.com \
--cc=rguenther@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).