On 06/27/14 08:26, David Malcolm wrote:
Yeah, that's probably my primary concern here. The patch kit is going
to be big (currently at 133 patches [1]), and so I want something that
we can sanely keep track of, that is easily reviewable, and will be as
easy as possible to merge.
i.e. I don't wa
On Wed, 2014-06-25 at 10:36 +0100, Richard Sandiford wrote:
> Oleg Endo writes:
> > Personally, I'd like to see usage of standard STL-like iterator usage.
> > I've proposed something for edge_iterator a while ago, but people don't
> > seem very fond of it. See also
> > https://gcc.gnu.org/ml/gcc-
On Wed, 2014-06-25 at 14:39 -0600, Jeff Law wrote:
> On 06/25/14 03:36, Richard Sandiford wrote:
> >
> > I think this is an example of another problem with gcc coding style:
> > that we're far too afraid of temporary variables. In David's scheme
> > I think this would be:
> Historical coding style
On Wed, 2014-06-25 at 10:36 +0100, Richard Sandiford wrote:
> Oleg Endo writes:
> > Personally, I'd like to see usage of standard STL-like iterator usage.
> > I've proposed something for edge_iterator a while ago, but people don't
> > seem very fond of it. See also
> > https://gcc.gnu.org/ml/gcc-
On Wed, Jun 25, 2014 at 10:46 PM, Jeff Law wrote:
> On 06/25/14 02:54, Richard Sandiford wrote:
>>
>> SEQUENCE is just weird though :-) It would be good to have an alternative
>> representation, but that'd be a lot of work on reorg.
>
> Yea. And I don't think anyone is keen on rewriting reorg.
R
On 06/25/14 02:54, Richard Sandiford wrote:
and the code now uses "rtx_insn *" in hundreds of places where it would
previously have used "rtx".
This looks really good to me FWIW. The only thing I'm not sure about is
how useful rtx_nonjump_insn would be. ISTM that jump_insn and call_insn
real
On 06/25/14 03:36, Richard Sandiford wrote:
I think this is an example of another problem with gcc coding style:
that we're far too afraid of temporary variables. In David's scheme
I think this would be:
Historical coding style :(It's particularly bad in RTL land, but you
see the same prob
Oleg Endo writes:
> Personally, I'd like to see usage of standard STL-like iterator usage.
> I've proposed something for edge_iterator a while ago, but people don't
> seem very fond of it. See also
> https://gcc.gnu.org/ml/gcc-patches/2013-12/msg01129.html
>
> Have you also considered passing the
David Malcolm writes:
> On Mon, 2014-06-09 at 20:32 +0100, Richard Sandiford wrote:
>> Steven Bosscher writes:
>> > On Sat, Jun 7, 2014 at 7:54 PM, Richard Sandiford wrote:
>> >> The two parts of the loop condition are really handling two different
>> >> kinds of block: ones like entry and exit t
On Mon, 2014-06-23 at 14:54 -0400, David Malcolm wrote:
> FWIW I'm actually working on such a change, or, at least, to make
> instructions be a subclass of rtx_def; presumably this should make it
> easier to make it an entirely separate type, if that's desirable.
>
> Executive summary is that it'
On Mon, 2014-06-09 at 20:32 +0100, Richard Sandiford wrote:
> Steven Bosscher writes:
> > On Sat, Jun 7, 2014 at 7:54 PM, Richard Sandiford wrote:
> >> The two parts of the loop condition are really handling two different
> >> kinds of block: ones like entry and exit that are completely empty
> >>
Steven Bosscher writes:
> On Sat, Jun 7, 2014 at 7:54 PM, Richard Sandiford wrote:
>> The two parts of the loop condition are really handling two different
>> kinds of block: ones like entry and exit that are completely empty
>> and normal ones that have at least a block note. There's no real
>>
On Sat, Jun 7, 2014 at 7:54 PM, Richard Sandiford wrote:
> The two parts of the loop condition are really handling two different
> kinds of block: ones like entry and exit that are completely empty
> and normal ones that have at least a block note. There's no real
> need to check for null INSNs in
13 matches
Mail list logo
