Thank you all for the suggestions.
This is first patch where I have just defined a struct libcall_arg_t
which contains
three member rtx, machine_mode and a boolean unsigned_p and will be
used in passing args in
emit_library_[call/value] functions.
Once this patch is approved then i will create second patch in which
arg type libcall_arg_t will be
propogated on all instances needed.
Then final patch which will fix the actual problem reported in PR88877.
ChangeLog Entry:
2020-06-13 Kamlesh Kumar <kamleshbha...@gmail.com>
* rtl.h (libcall_arg_t): Defined.
---
diff --git a/gcc/rtl.h b/gcc/rtl.h
index 0872cc4..c023ff0 100644
--- a/gcc/rtl.h
+++ b/gcc/rtl.h
@@ -2238,6 +2238,18 @@ struct address_info {
enum rtx_code base_outer_code;
};
+/* This is used for passing args in emit_library_* functions */
+typedef struct libcall_arg {
+ rtx value;
+ machine_mode mode;
+ bool unsigned_p;
+ libcall_arg (rtx v, machine_mode m, bool u) {
+ value = v;
+ mode = m;
+ unsigned_p = u;
+ }
+} libcall_arg_t;
+
/* This is used to bundle an rtx and a mode together so that the pair
can be used with the wi:: routines. If we ever put modes into rtx
integer constants, this should go away and then just pass an rtx in. */
--
2.7.4
On Fri, Jun 12, 2020 at 4:43 AM Segher Boessenkool
<seg...@kernel.crashing.org> wrote:
>
> On Tue, Jun 09, 2020 at 02:29:13PM -0600, Jeff Law wrote:
> > On Sun, 2020-05-24 at 11:22 -0500, Segher Boessenkool wrote:
> > > OTOH, you don't need to name Tuple at all... It should not *have* a
> > > constructor, since you declared it as class... But you can just use
> > > std::tuple here?
> > >
> > > > (emit_library_call): Added default arg unsigned_p.
> > > > (emit_library_call_value): Added default arg unsigned_p.
> > >
> > > Yeah, eww. Default arguments have all the problems you had before,
> > > except now it is hidden and much more surprising.
> > >
> > > Those functions really should take rtx_mode_t arguments?
> > >
> > > Thanks again for working on this,
> > ISTM that using std::tuple would be better than defining our own types.
>
> Yeah. But as Jakub an Iain said, not using a container type (but a more
> concrete type, instead) is much better anyway :-)
>
> > I'd rather see the argument be explicit rather than using default arguments
> > too.
> > While I have ack'd some patches with default arguments, I still don't like
> > 'em.
>
> Default arguments have their place (but it's not here :-) )
>
> > I do like the approach of getting the infrastructure in place without
> > changing
> > behavior, then having the behavior fix as a distinct change.
>
> With Git, commits are easy and cheap, and massaging a patch series into
> shape is easy and cheap as well. If you develop using Git in the first
> place (and you should!), you should naturally end up with many patches
> in your series, and the preparatory patches first (after you reshuffle
> things a bit, if you are like me and your foresight is severly limited).
>
> So you have this separate *anyway* (or should have). Since it helps
> reviewing a lot, and also later bisecting, it is good to keep it.
>
>
> Segher
