On Sun, 13 Aug 2023, Martin Jambor wrote:
> Hello Richi,
>
> it took me quite time to get back to this but it might have actually
> helped because it forced me to re-read the code around and in turn
> simplify the patch.
>
> On Mon, Jun 12 2023, Richard Biener wrote:
> > On Fri, 9 Jun 2023, Mart
Hello Richi,
it took me quite time to get back to this but it might have actually
helped because it forced me to re-read the code around and in turn
simplify the patch.
On Mon, Jun 12 2023, Richard Biener wrote:
> On Fri, 9 Jun 2023, Martin Jambor wrote:
>
[...]
>> @@ -2327,7 +2330,7 @@ vn_walk
ssing
> > op->base directly.
>
> OK
>
> >
> >> +HOST_WIDE_INT offset, size;
> >> +bool reverse;
> >> +tree base = get_ref_base_and_extent_hwi (op->ref, &offset,
> >> + &size, &r
_zerop (TREE_OPERAND (base, 1))
>> + && TREE_CODE (TREE_OPERAND (base, 0)) == SSA_NAME
>
> And this then should be done within the above branch as well,
> just keyed off base == MEM_REF.
I am sorry but I don't understand this comment, can you please try to
re-phr
On Mon, 29 May 2023, Martin Jambor wrote:
> Hi,
>
> PRs 68930 and 92497 show that when IPA-CP figures out constants in
> aggregate parameters or when passed by reference but the loads happen
> in an inlined function the information is lost. This happens even
> when the inlined function itself wa
Hi,
PRs 68930 and 92497 show that when IPA-CP figures out constants in
aggregate parameters or when passed by reference but the loads happen
in an inlined function the information is lost. This happens even
when the inlined function itself was known to have - or even cloned to
have - such constan
