default is an appropriate option. It should be switched
back on stage 1 and/or minor releases.
Seems reasonable to me. It's a nice safe default ;-) Folks can enable
it easily when building GCC.
jeff
last
update on this page was around 3 years ago). Also, how feasible is
this for GSoc?
Certainly still useful, the trick is finding a hunk of that work that
can be tackled via GSoc.
jeff
On 02/23/15 14:41, H.J. Lu wrote:
On Mon, Sep 29, 2014 at 4:00 AM, Jakub Jelinek wrote:
On Mon, Sep 29, 2014 at 12:56:06PM +0200, Thomas Schwinge wrote:
Hi!
On Tue, 23 Sep 2014 11:02:30 +, "Zamyatin, Igor"
wrote:
Jeff Law wrote:
The original plan was for Balaji to take on
On 03/05/15 17:41, Thomas Schwinge wrote:
Hi!
On Thu, 5 Mar 2015 13:39:44 -0700, Jeff Law wrote:
On 02/23/15 14:41, H.J. Lu wrote:
On Mon, Sep 29, 2014 at 4:00 AM, Jakub Jelinek wrote:
On Mon, Sep 29, 2014 at 12:56:06PM +0200, Thomas Schwinge wrote:
On Tue, 23 Sep 2014 11:02:30 +
hanks.
Would it make sense for someone to pick this
https://gcc.gnu.org/wiki/GimpleFrontEnd
up where it was left off?
Absolutely. Especially since it's a necessary step towards unit testing
of the gimple optimizers.
Jeff
On 03/06/15 18:22, Mikhail Maltsev wrote:
05.03.2015 18:46, Jeff Law wrote:
Certainly still useful, the trick is finding a hunk of that work that
can be tackled via GSoc.
jeff
Though I'm not participating in GSoC, I would be glad to get involved in
GCC development.
Could you please
nt.
It also doesn't fit well into the long term plans to change the
threader from a forward walk to a backward walk.
LLVM has integrated a very limited form of this transformation into
their jump threader, specifically for memory loads.
Jeff
ssure implications of duplicating the contents of the join
block into its predecessors, leaving an empty joiner so that we still
have a single latch?
Jeff
On 03/09/15 05:40, Richard Biener wrote:
On Sun, Mar 8, 2015 at 8:49 PM, Jeff Law wrote:
On 03/08/15 12:13, Richard Biener wrote:
I see. This basically creates two loop latches and thus will make our
loop detection code turn the loop into a fake loop nest. Not sure if that
is a good idea
pattern fubar, you can emit an insn with that
pattern using emit_insn (gen_fubar (arguments)))
jeff
re difficult than it ought to be :(
But I won't start a rant on that issue right now ;-)
Jeff
have two
instances of the loop, one for the THEN, the other for the ELSE. You
obviously select one or the other based on the condition of V.
Specific examples might be helpful in understanding how you see this as
different than unswitching.
jeff
On 03/16/2015 09:45 PM, Ajit Kumar Agarwal wrote:
-Original Message-
From: Jeff Law [mailto:l...@redhat.com]
Sent: Monday, March 16, 2015 11:45 PM
To: Ajit Kumar Agarwal; Richard Biener; gcc@gcc.gnu.org
Cc: Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala
in the graph are allowed only a single
static assignment. Thus if you copy a block all SSA_NAMEs in the block
have to go through an SSA update to ensure that each has one and only
one single static assignment.
jeff
; way to do that. You'll need to
hack somethign up.
jeff
On 03/17/2015 09:50 PM, Mikhail Maltsev wrote:
07.03.2015 18:41, Jeff Law wrote:
One potentially easy project there would be to take David Malcolm's work to
turn the RTL EXPR & INSN lists into standard C++ forward lists.
Started working on this. I need to understand, if I'm
things via EXPR_LIST or INSN_LIST.
Jeff
. The following
do not even complete building gcc+newlib.
v850 - PR65501. New and must be relatively recent. I built
a C/C++ toolset on January 15.
Presumably v850 was working before, so this BZ needs a regression marker.
Jeff
suitable for a GSOC project than tackling the entire
space of address mode selections.
jeff
mp; Kyrylo, if you could add yourself to the MAINTAINERS file for
the additional roles, it would be appreciated.
Thanks,
Jeff
ion so I
haven't pushed it forward and probably won't until stage1 reopens.
jeff
ot exactly straight forward.
David has some code that allows creation of gimple on the fly and
feeding it to a pass which is obviously designed with unit testing in mind.
Jeff
fies the result. What
I'm struggling with here is balancing the human cost of building a test
in David's kind of framework vs doing something easier in a gimple-FE
like framework vs what we do now where it's bloody hard to arrange for
bits to get to a specific pass in a specific state.
jeff
after LLVM's representation?
Jeff
On 04/03/2015 09:41 AM, Diego Novillo wrote:
On Fri, Apr 3, 2015 at 11:35 AM, Jeff Law wrote:
I was hesitant to offer this option, but it's certainly a good
starting point. The representation encodes CFG, SSA, attributes,
declarations and annotations. It has a relatively fixed syntax,
ases i1 has the note i2, no note and
i1 has no note and i2 has a note.
Jeff
jeff
On 03/10/2015 07:40 AM, BELBACHIR Selim wrote:
Me again :)
I enhanced my patch because it was not generalized for instructions with N
delay_slots.
Mostly OK, though there are some formatting nits that need to be corrected.
We have whitespace around arithmetic, logical and comparison operators
works on pseudos.
jeff
ng problems and installed your
change on the trunk.
jeff
I'm pleased to announce that Segher Boessenkool has been appointed as
maintainer for instruction combiner (combine.c).
Segher, can you please add yourself to the MAINTAINERS file for the
additional role.
Thanks,
jeff
On 04/20/2015 01:09 AM, Shiva Chen wrote:
Hi, Jeff
Thanks for your advice.
can_replace_by.patch is the new patch to handle both cases.
pr43920-2.c.244r.jump2.ori is the original jump2 rtl dump
pr43920-2.c.244r.jump2.patch_can_replace_by is the jump2 rtl dump
after patch
arning, no :-) That pretty
seriously buggy!
It may also have been poor timing on installing the OS and initial
upgrading of all the packages
shell.devel.redhat.com/~law has a 4.0 kernel with the tty fix if you
don't want to try and downgrade.
jeff
ne forgets about the unfinished record_type.
For a different cv-quals of the same record type one builds a new cv-qualified
record from scratch.
I'm a bit surprised the former didn't work, but if the latter is working
consistently, then I'd stick with it.
jeff
On 03/18/2015 01:21 PM, Oleg Endo wrote:
On Tue, 2015-03-17 at 22:31 -0600, Jeff Law wrote:
I'm not a big fan of keeping the FOR_EACH_blah style iterator and would
prefer to use real C++ iterators. But it ought to give you some ideas
about how to start breaking these things out.
BTW
was last discussed with Zdenek. I think the fundamental issue is we
can't really predict when threading the loop is going to interfere with
later optimizations or not. The heuristics we have are marginal at best.
The one thought we've never explored was re-rolling that first iteration
back into the loop in the vectorizer.
Jeff
On 04/27/2015 01:06 PM, Adrian Chadd wrote:
Hi!
I'd like to contribute some FreeBSD patches to gcc. I believe I have
to sign some copyright assignment stuff. What do I need?
Please contact ass...@gnu.org. They ought to be able to get you the
appropriate paperwork.
Jeff
y haven't really investigated) that the CFG will
have tell-tale signs and that we then look at the key blocks.
Jeff
It also helps if you can show real
world cases where it helps and the domains where the transformations
result in unexpected results.
Ultimately it's a judgment call based on those kind of factors.
jeff
rty in IEEE 754, 16,777,217,
converts to 16,777,216 in float. I'm not a math expert
but such a result would seem unexpected even with
-ffast-math.
Yeah, such changes would be not welcome with -ffast-math.
Agreed.
jeff
p_insn_before (gen_jump (XEXP (src, 0)),
insn);
JUMP_LABEL (new_rtx) = XEXP (src, 0);
LABEL_NUSES (XEXP (src, 0))++;
And it almost certainly should be calling into the cfgrtl.c routines
instead.
jeff
L_REF
&& LABEL_REF_NONLOCAL_P (trial))
continue;
SET_SRC (sets[i].rtl) = trial;
cse_jumps_altered = true;
break;
}
on the jump insn and with trial = (label_ref 83).
The code pointed out by Jeff then replaces the original jump insn by
(jump_
t, try_redirect_by_replacing_jump might "just
work". It's something you'll need to play a bit with to find the right
bits to wire up.
jeff
s the capabilities of PPC and HPPA
at the time.
We'd certainly welcome patches to support scaling in the pre/post_modify
addressing modes.
jeff
d sharing subregs for the
correct LRA/reload work.
If their code is sharing subregs, then most definitely that code is
wrong. GCC has very well defined rtx sharing rules that are defined in
the developer documentation.
jeff
ent is
needed. If you don't have all that setup properly prior to the
allocators, then they're not going to know how what objects to align nor
how to align them.
jeff
{
+ process_path_splitting(bb);
So instead of running this as a subroutine of vrp, make it a first class
pass. Then find the right place to put the pass. I think that'll
ultimately be cleaner and simpler as you won't be trying to duplicate
things like const/copy propagation.
Overall I like the the transformation you're trying to make, but would
like to see this as a separate pass, if it can't be a separate pass,
please indicate why. Second, you should be looking to re-use existing
block duplication routines, SSA updating, etc as much as possible.
jeff
I
conversion to clear the upper bits, and it seems to work, but I wonder
if it's the ideal solution...
Looks wrong to me -- but the s390 maintainers ought to chime in.
jeff
revent reload from messing things up:
https://gcc.gnu.org/ml/gcc-patches/2006-03/msg01495.html
I don't know if this is still necessary though.
Looks like a hack to me. Sadly, no testcase in that BZ, though
presumably since it was a bootstrap failure one could checkout a
development tree from that era and see the failure.
jeff
is:
You should debug precisely where that came from. You're missing
something in your backend to tell GCC that such constants are not valid.
You should probably look at how expansion occurs for your tests on other
ports that make heavy use of high/lo_sum. sparc & hppa come immediately
to mind, but I'm sure there's others.
jeff
s in the constant pool, thus
force_const_mem may return NULL_RTX. */
if (tem && memory_address_p (...))
Jeff
's a form of propagation missing, we should enhance the
propagation routines to handle the missing cases rather than write new
ones inside a pass.
jeff
if with an initial x = x.
The later patterns require jumps to be more expensive.
??? For future expansion, look for multiple X in such patterns. */
I think folks would look favorably upon removing that limitation,
obviously with some kind of cost checking.
Jeff
tle while
back, not sure if it makes any significant difference in the analysis
though.
The only other thing that comes immediately to mind would be secondary
reloads. But I always hate suggesting them.
Jeff
desirable way to fix the problem.
jeff
I'm pleased to announce James Bowman has been appointed as the
maintainer for the FT32 port.
James, can you please add yourself to the MAINTAINERS file.
Thanks,
Jeff
nfrastructure in place to
optimize builtins and chains of builtins. If something is missing, we
definitely want to know about it so that it can be corrected.
jeff
On 08/28/2018 05:40 PM, Segher Boessenkool wrote:
> On Mon, Aug 20, 2018 at 11:01:29AM -0600, Jeff Law wrote:
>> On 08/20/2018 10:50 AM, Paul Koning wrote:
>>> The internals manual seems to say that memory subregs are an old mechanism
>>> that should still work, give or
,
> then
> use all the constraints as one alternative in my pattern.
>
> Is there a better method?
>
> Is there some small change that could enable a nicer method?
It would help to know more about when you want to allow odd registers.
I'd be surprised if creating a class, but still rejecting in
HARD_REGNO_MODE_OK worked...
Jeff
ning appear inconsistent, both between
> languages, and in C, between optimization levels. Delaying
> the warning until a later stage (e.g., until folding as Jason
> suggested) would make it more consistent. It wouldn't solve
> all problems (e.g., it would still be prone to false positives
> in unreachable code), but solving those by delaying it even
> further could easily lead to others.
We have long wanted to defer all the transformations in
shorten_binary_op and its close cousins. They really should be match.pd
patterns.
Kai and I did some poking around in this space a while back but nothing
that was mature enough to incorporate into the tree.
jeff
>
> Martin
s code
generation bugs. While we do make some exceptions, those are good
general guidelines.
I don't think the qsort changes warrant an exception.
jeff
"-fno-ipa-vrp",
> "-fmath-errno",
> -"-Warray-temporaries",
> "-Wno-unused-label",
> "-Wreturn-local-addr",
> "--param=sms-dfa-history",
>
> AG
>
They're Fortran specific options. I'm not sure how that impacts your
tests though.
jeff
an_create_pseudo_p() (!reload_in_progress && !reload_completed)
>
> Is it deliberate that it doesn't check lra_in_progress?
I think its deliberate. IRA and I believe LRA can create pseudos while
they are running. Vlad would know for certain.
Jeff
sed
>>> to be evaluated only in compilation time to evaluate the code size.
>>
>> But this is a misconception about __builtin_constant_p. It doesn't guard sth
>> like 'constexpr' regions. If you try to use it with those semantics you'll
>> fail (appearantly you do).
>>
>> Of course IPA CP code size estimates when seeing a constant fed to bcp might
>> be not optimal, that's another issue of course.
>
> I understand that this is might not be the right way to implement macros
> such as ilog2() and test_bit(), but this code is around for some time.
That doesn't make it right -- and there's been numerous bogus bugs
reported against ilog2 because the authors of ilog2 haven't had a clear
understanding of the semantics of builtin_constant_p.
Jeff
to fit in the 16 bit address space of the target.
>
> I changed the board file to specify a linker script with explicit memory
> bounds, and a torture options override that omits the -O3 variants. Now I
> get sane results.
>
Yea. You also have to watch out for things which fit in the memory map
statically but where your stack/heap will collide at runtime. I saw
this all the time when I used to do embedded work on 16 bit targets.
jeff
hould be skipped by any target that
>> can't do ieee at all.
>
> No, that's not how things are supposed to work. Look at c99_runtime for
> example: we have both
>
> dg-require-effective-target c99_runtime
>
> which checks if the targets supports a C99 runtime, and
>
> dg-add-options c99_runtime
>
> to add special options for targets that need them.
>
> I've no idea why this isn't the case for ieee today.
Probably because we've buried a lot of the ieee specific stuff into
c-torture/{compile,execute}/ieee
jeff
already benefit from make
> parallelism remains a question.
Agreed. Driving down the amount of global state is good in and of
itself. It's also a prerequisite for parallelizing GCC itself using
threads.
I suspect driving down global state probably isn't that interesting for
a master's thesis though :-)
jeff
On 11/20/18 11:07 AM, Michael Eager wrote:
> On 11/18/2018 08:14 AM, Jeff Law wrote:
>> On 11/18/18 8:44 AM, Michael Eager wrote:
>>> On 11/16/18 14:50, Segher Boessenkool wrote:
>>>> Hi!
>>>>
>>>> On Wed, Nov 14, 2018 at 11:22:58AM -0800, M
e an argument to warn for them.
Whether or not to warn in general if the alignment attribute is smaller
than the default may be subject to debate. I guess it depends on the
general intent that we'd find in real world codes.
jeff
ich comes into play during generation of the initial
trees as well in passes which try to optimize branchy code into
straighter code.
jeff
On 11/28/18 10:47 AM, Michael Eager wrote:
> On 11/28/18 09:10, Jeff Law wrote:
>> On 11/28/18 10:00 AM, Michael Eager wrote:
>>> I have a small test case which generates poor quality code on my target.
>>> Here is the original:
>>>
>>> if (cond1 =
onale, historical context, etc. Just because we're
changing a comment doesn't mean it's inherently trivial/obvious.
I'm generally supportive of lessening friction for developers and I
welcome proposals to do that.
Jeff
On 11/27/18 11:57 AM, Martin Sebor wrote:
> On 11/26/18 3:37 PM, Jeff Law wrote:
>> On 11/23/18 12:31 PM, Martin Sebor wrote:
>>> GCC currently accepts the declaration of f0 below but ignores
>>> the attribute. On aarch64 (and I presume on other targets with
>&
nt
object. If you restrict memory ops to QImode, then you resolve that
problem.
But we're unlikely to get a definitive answer here.
I think the real question is can we reasonably lift the restriction.
Jeff
On 11/30/18 12:39 AM, Richard Biener wrote:
> On Wed, Nov 28, 2018 at 6:10 PM Jeff Law wrote:
>>
>> On 11/28/18 10:00 AM, Michael Eager wrote:
>>> I have a small test case which generates poor quality code on my target.
>>> Here is the original:
>>
On 11/30/18 9:14 AM, Jakub Jelinek wrote:
> On Fri, Nov 30, 2018 at 09:08:34AM -0700, Jeff Law wrote:
>>> Sth I don't like very much... maybe we can revisit removing
>>> the few cases in fold-const.c (thus GENERIC folding) and rely
>>> on later GIMPLE pass
GCC round it up as necessary, with no warning. So I'd make
> the new warning off by default.
That seems like a better UI than forcing the user to know what their
target actually supports.
So, yea I think I'm in agreement with where you're going.
jeff
UNSUBSCRIBE
s to stress compilers.
I have a lot of respect for John's work. It's too bad I don't see him
more often. He's only 15 minutes up the road working with my old group
at the U.
jeff
o "over"
optimization in the RTL space.
[ ... ]
>
> so the generated GIMPLE was "tuned" for reasonable x86 assembler outcome.
>
> Patch below for reference (and your own testing in case you are curious).
> I do not plan to pursue this further at this point.
Understood. Thanks for posting it. We're not currently working in this
space, but again, we may re-evaluate that stance in the future.
jeff
e.
>
> This is essentially https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30612
Anyone working in this space should probably look at Ian's blogpost.
https://www.airs.com/blog/archives/499
jeff
nge in static data. So I don't think your patch is a degradation
over the current state. I'm not 100% sure the current state is correct
though :-)
jeff
;
> let me know your opinion.
>
> thanks a lot for the help.
I think we (Richi and I) went through this about a year ago and the
conclusion was we should be looking at how you're getting into the
vrp_meet with the VR_UNDEFINED.
If it happens because the user's code has an undefined use, then, the
consensus has been to go ahead and optimize it.
If it happens for any other reason, then it's likely a bug in GCC. We
had a couple of these when we made EVRP a re-usable module and started
exploiting its data in the jump threader.
So you need to work backwards from this point to figure out how you got
here.
jeff
e in the CFG are often
a source of false positives when folks use -O1, -Os and profile directed
optimizations. Bodik has some thoughts in this space, but I haven't
really looked to see how feasible they are in the real world.
>
> * Bug fixing in the C++ frontend / general C++ frontend improvements
> There are 100s of open PRs about the C++ frontend, and the goal here
> would just be to resolve as many as one can over the summer.
Bugfixing is always good :-)
jeff
On 3/1/19 10:49 AM, Qing Zhao wrote:
> Jeff,
>
> thanks a lot for the reply.
>
> this is really helpful.
>
> I double checked the dumped intermediate file for pass “dom3", and
> located the following for _152:
>
> BEFORE the pass “dom3”, there is no _1
On 3/4/19 4:45 AM, Richard Biener wrote:
> On Fri, Mar 1, 2019 at 10:02 PM Qing Zhao wrote:
>>
>>
>> On Mar 1, 2019, at 1:25 PM, Richard Biener
>> wrote:
>>
>> On March 1, 2019 6:49:20 PM GMT+01:00, Qing Zhao
>> wrote:
>>
>> Jeff,
>&
stmts created by folding.
>
> * gcc.dg/torture/pr89595.c: New testcase.
>
Well, all the real logic changs are in the before_dom_children method.
The bits in optimize_stmt are trivial enough to effectively ignore.
I don't see a better way to discover and process statements that are
created in the bowels of fold_stmt.
Jeff
ve; i386.c is way too long as it is. 7 pieces sounds like a good
> number of new files to split it into, too.
I trust your judgment on where/how to split and fully support the goals
behind splitting. Uros is the key person you need to get on board.
jeff
On 3/6/19 3:05 AM, Richard Biener wrote:
> On Tue, Mar 5, 2019 at 10:36 PM Jeff Law wrote:
>>
>> On 3/5/19 7:44 AM, Richard Biener wrote:
>>
>>> So fixing it properly with also re-optimize_stmt those stmts so we'd CSE
>>> the MAX_EXPR
te dead stores
problems that are in BZ as well as some of the uninit issues for memory
references that's been rattling around in my head. It's also related
to SRA. Richi has stated (and I tend to agree) there's a goodly amount
of common analysis that can probably be shared across these problems.
I don't know if there's a grand unifying analysis that will tackle all
of this, but it certainly feels like there's at least something worth
exploring in this space.
Jeff
r ops (pdp11 has
> separate floating point conditions, vax doesn't).
Right. Another port one could look at which recently went through this
transition is the v850.
Jeff
thin longlong.h, then yes, you can just
go ahead and apply your fix.
Jeff
gcc/ChangeLog:
>
> * config.gcc: Mark spu* targets as deprecated/obsolete.
WOrks for me as well.
jeff
its PS3 supercomputer cluster... (I'd have to check to
> make sure...)
Even if there's potentially still users out there, if there's no
maintainer to support the target, then it should be deprecated.
Of course, you could always step into that role. I'm sure Ulrich could
fill you in on the responsibilities.
jeff
who would be the mentor, would chime in
> earlier. But unfortunately he has probably not been online in the past
> few days. (And I admit I struggle a little bit to answer all GSoC email
> in a timely manner this week too).
Jakub is on PTO this week. He'll be back in the office Monday.
jeff
gt;
> No, this would imply deleting the stage2 and stage3 compilers and that isn't
> what happens. Instead the compiler of each stage is updated in isolation.
>
RIght. Thus I always blow away stage2-* stage3-*, and stage1 target
directories along with the "compare" stamp file.
Jeff
On 4/5/19 3:37 PM, Martin Sebor wrote:
> On 4/5/19 3:29 PM, Jeff Law wrote:
>> On 4/5/19 2:50 PM, Eric Botcazou wrote:
>>>> Say if the first bootstrap succeeds and I then change a single
>>>> GCC .c file and rerun make bootstrap, am I guaranteed to see
>>
On 4/8/19 3:19 AM, Richard Biener wrote:
> On Sat, Apr 6, 2019 at 1:09 AM Martin Sebor wrote:
>>
>> On 4/5/19 4:02 PM, Jeff Law wrote:
>>> On 4/5/19 3:37 PM, Martin Sebor wrote:
>>>> On 4/5/19 3:29 PM, Jeff Law wrote:
>>>>> On 4/5/19 2:5
On 4/1/19 6:40 PM, Patrick Palka wrote:
> On Sun, Mar 3, 2019 at 5:16 PM Jeff Law wrote:
>>
>> On 3/3/19 4:06 PM, Patrick Palka wrote:
>>> Hi everyone,
>>>
>>> I am very interested in working on GCC as part of GSoC this year. A few
>>> years
th gcc-9 issues as we approach the upcoming release. Hopefully
he'll have time to review this once crunch time has past. I think more
than anything sanity checking the proposal's requirements vs what can be
reasonably implmemented is most important at this stage.
Jeff
mething about that one day.
I'd be happy to get things sorted out up to the RTL transition,
particularly the cases involving equivalences. Distinguishing between
pointer and same sized integers in RTL will be difficult.
jeff
401 - 500 of 1403 matches
Mail list logo
