On Mon, May 20, 2019 at 01:31:10PM -0600, Jeff Law wrote:
> On 5/15/19 10:44 AM, Segher Boessenkool wrote:
> > But we can be allocated a floating point register, or memory, instead.
> > That is heavily discouraged (by making it more expensive), but it can
> > still happen. This is a jump_insn so i
On 5/15/19 10:44 AM, Segher Boessenkool wrote:
> On Wed, May 15, 2019 at 10:53:43AM +0200, Richard Biener wrote:
>> I wonder if making the doloop patterns (tried to find them in rs6000.md,
>> but I only see define_expands with no predicates/alternatives...)
>
> "doloop_end" --> "ctr" --> "_"
> (al
On Wed, May 15, 2019 at 10:53:43AM +0200, Richard Biener wrote:
> I wonder if making the doloop patterns (tried to find them in rs6000.md,
> but I only see define_expands with no predicates/alternatives...)
"doloop_end" --> "ctr" --> "_"
(all consecutive in rs6000.md btw.) Alternative 0 in "_"
ar
On Wed, 15 May 2019, Segher Boessenkool wrote:
> On Wed, May 15, 2019 at 10:40:09AM +0800, Bin.Cheng wrote:
> > I wonder if you can factor out generic part into GIMPLE and leave
> > target hook as specific as possible?
>
> Less GIMPLE handling code in the backend would probably be good, yes. Les
On Tue, 14 May 2019, Bill Schmidt wrote:
> On 5/14/19 2:13 PM, Jeff Law wrote:
> > On 5/13/19 9:09 PM, li...@linux.ibm.com wrote:
> >> From: Kewen Lin
> >>
> >> Previous version link for background:
> >> https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00912.html
> >>
> >> This hook is to predict wh
On Wed, May 15, 2019 at 10:40:09AM +0800, Bin.Cheng wrote:
> I wonder if you can factor out generic part into GIMPLE and leave
> target hook as specific as possible?
Less GIMPLE handling code in the backend would probably be good, yes. Less
of the mechanics at least.
> > +static bool
> > +invali
On Wed, May 15, 2019 at 1:20 PM Kewen.Lin wrote:
>
> on 2019/5/15 上午11:34, Kewen.Lin wrote:
> >
> > on 2019/5/15 上午10:40, Bin.Cheng wrote:
> >> I wonder if you can factor out generic part into GIMPLE and leave
> >> target hook as specific as possible?
> >>
> >
> > Good suggestion! Yes, most of the
on 2019/5/15 上午11:34, Kewen.Lin wrote:
>
> on 2019/5/15 上午10:40, Bin.Cheng wrote:
>> I wonder if you can factor out generic part into GIMPLE and leave
>> target hook as specific as possible?
>>
>
> Good suggestion! Yes, most of the checks are common as you
> pointed out. I hope the other targets
on 2019/5/15 上午10:40, Bin.Cheng wrote:
> I wonder if you can factor out generic part into GIMPLE and leave
> target hook as specific as possible?
>
Good suggestion! Yes, most of the checks are common as you
pointed out. I hope the other targets won't have more
customization needs excepting for
on 2019/5/14 下午3:24, Richard Biener wrote:>
> Most of the rs6000 target hook checks look general
> (can we compute niter, etc.), IVOPTs would have a hard
> time adding a counter IV w/o being able to compute niters.
Do you mean to reuse them?
Yes, IVOPTs has already checked niter. At the initial
I wonder if you can factor out generic part into GIMPLE and leave
target hook as specific as possible?
On Tue, May 14, 2019 at 11:10 AM wrote:
>
> From: Kewen Lin
>
> Previous version link for background:
> https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00912.html
>
> This hook is to predict whet
On Tue, May 14, 2019 at 01:13:34PM -0600, Jeff Law wrote:
> Trying to guess what the target is going to do, then changing the
> structure of the loops in gimple based on that guess -- is that really a
> good idea. It's fairly counter to many of the design goals around gimple.
That is exactly what
On 5/14/19 1:35 PM, Bill Schmidt wrote:
> On 5/14/19 2:13 PM, Jeff Law wrote:
>> On 5/13/19 9:09 PM, li...@linux.ibm.com wrote:
>>> From: Kewen Lin
>>>
>>> Previous version link for background:
>>> https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00912.html
>>>
>>> This hook is to predict whether one
On 5/14/19 2:13 PM, Jeff Law wrote:
> On 5/13/19 9:09 PM, li...@linux.ibm.com wrote:
>> From: Kewen Lin
>>
>> Previous version link for background:
>> https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00912.html
>>
>> This hook is to predict whether one loop in gimple will
>> be transformed to low-ove
On 5/13/19 9:09 PM, li...@linux.ibm.com wrote:
> From: Kewen Lin
>
> Previous version link for background:
> https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00912.html
>
> This hook is to predict whether one loop in gimple will
> be transformed to low-overhead loop later in RTL, and
> designed to
On Tue, May 14, 2019 at 5:10 AM wrote:
>
> From: Kewen Lin
>
> Previous version link for background:
> https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00912.html
>
> This hook is to predict whether one loop in gimple will
> be transformed to low-overhead loop later in RTL, and
> designed to be call
From: Kewen Lin
Previous version link for background:
https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00912.html
This hook is to predict whether one loop in gimple will
be transformed to low-overhead loop later in RTL, and
designed to be called in ivopts.
"Since the low-overhead loop optimize tra
17 matches
Mail list logo
