on 2024/4/3 19:18, Jakub Jelinek wrote:
> On Wed, Apr 03, 2024 at 07:01:50PM +0800, Kewen.Lin wrote:
>> Thanks for the details on debugging support, but IIUC with this workaround
>> being adopted, the debuggability on hidden args are already broken, aren't?
>
> No.
> In the correct program case, w
On Wed, Apr 03, 2024 at 07:01:50PM +0800, Kewen.Lin wrote:
> Thanks for the details on debugging support, but IIUC with this workaround
> being adopted, the debuggability on hidden args are already broken, aren't?
No.
In the correct program case, which should be the usual case, the caller will
pas
Hi!
on 2024/4/3 17:23, Jakub Jelinek wrote:
> On Wed, Apr 03, 2024 at 05:02:40PM +0800, Kewen.Lin wrote:
>> on 2024/4/3 16:35, Jakub Jelinek wrote:
>>> On Wed, Apr 03, 2024 at 01:18:54PM +0800, Kewen.Lin wrote:
> I'd prefer not to remove DECL_ARGUMENTS chains, they are valid arguments
> t
On Wed, Apr 03, 2024 at 05:02:40PM +0800, Kewen.Lin wrote:
> on 2024/4/3 16:35, Jakub Jelinek wrote:
> > On Wed, Apr 03, 2024 at 01:18:54PM +0800, Kewen.Lin wrote:
> >>> I'd prefer not to remove DECL_ARGUMENTS chains, they are valid arguments
> >>> that just some
> >>> invalid code doesn't pass.
Hi Jakub,
on 2024/4/3 16:35, Jakub Jelinek wrote:
> On Wed, Apr 03, 2024 at 01:18:54PM +0800, Kewen.Lin wrote:
>>> I'd prefer not to remove DECL_ARGUMENTS chains, they are valid arguments
>>> that just some
>>> invalid code doesn't pass. By removing them you basically always create an
>>> invali
On Wed, Apr 03, 2024 at 01:18:54PM +0800, Kewen.Lin wrote:
> > I'd prefer not to remove DECL_ARGUMENTS chains, they are valid arguments
> > that just some
> > invalid code doesn't pass. By removing them you basically always create an
> > invalid case, this time in the other direction, valid calle
Hi Jakub,
on 2024/4/2 16:03, Jakub Jelinek wrote:
> On Tue, Apr 02, 2024 at 02:12:04PM +0800, Kewen.Lin wrote:
>> The old code for the unused hidden parameter (which was the 9th param)
>> would
>> fall thru to the "return NULL_RTX;" which would make the callee assume
>> there
>>>
On Tue, Apr 02, 2024 at 02:12:04PM +0800, Kewen.Lin wrote:
> The old code for the unused hidden parameter (which was the 9th param)
> would
> fall thru to the "return NULL_RTX;" which would make the callee assume
> there
> was a parameter save area allocated. Now instead
Hi!
on 2024/3/24 02:37, Ajit Agarwal wrote:
>
>
> On 23/03/24 9:33 pm, Peter Bergner wrote:
>> On 3/23/24 4:33 AM, Ajit Agarwal wrote:
> - else if (align_words < GP_ARG_NUM_REG)
> + else if (align_words < GP_ARG_NUM_REG
> +|| (cum->hidden_string_length
> +
On 23/03/24 9:33 pm, Peter Bergner wrote:
> On 3/23/24 4:33 AM, Ajit Agarwal wrote:
- else if (align_words < GP_ARG_NUM_REG)
+ else if (align_words < GP_ARG_NUM_REG
+ || (cum->hidden_string_length
+ && cum->actual_parm_length <= GP_ARG_NUM_REG))
>>>
On 3/23/24 4:33 AM, Ajit Agarwal wrote:
>>> - else if (align_words < GP_ARG_NUM_REG)
>>> + else if (align_words < GP_ARG_NUM_REG
>>> + || (cum->hidden_string_length
>>> + && cum->actual_parm_length <= GP_ARG_NUM_REG))
>> {
>> if (TARGET_32BIT && TARGET_
Hello Peter:
Sent version-3 of the patch addressing below review comments.
Thanks & Regards
Ajit
On 23/03/24 3:03 pm, Ajit Agarwal wrote:
> Hello Peter:
>
> On 23/03/24 10:07 am, Peter Bergner wrote:
>> On 3/22/24 5:15 AM, Ajit Agarwal wrote:
>>> When using FlexiBLAS with OpenBLAS we noticed co
Hello Peter:
On 23/03/24 10:07 am, Peter Bergner wrote:
> On 3/22/24 5:15 AM, Ajit Agarwal wrote:
>> When using FlexiBLAS with OpenBLAS we noticed corruption of
>> the parameters passed to OpenBLAS functions. FlexiBLAS
>> basically provides a BLAS interface where each function
>> is a stub that fo
On 3/22/24 5:15 AM, Ajit Agarwal wrote:
> When using FlexiBLAS with OpenBLAS we noticed corruption of
> the parameters passed to OpenBLAS functions. FlexiBLAS
> basically provides a BLAS interface where each function
> is a stub that forwards the arguments to a real BLAS lib,
> like OpenBLAS.
>
>
14 matches
Mail list logo
