On 3/19/25 4:14 AM, Georg-Johann Lay wrote:
Am 16.03.25 um 14:51 schrieb Jeff Law via Gcc:
On 3/13/25 5:39 AM, Georg-Johann Lay via Gcc wrote:
There are situations where knowledge about which bits
of a value are (not) set can be used for optimization.
For example in an insn combine pattern
ou could always reach out to Mark to get the most up-to-date status.
Jeff
er capable the target design is, the
less useful sched1 will be.
Jeff
w the
bit position is not bit 31.
There's no way to really describe that in an insn's condition because
range information like that isn't available in RTL and something like
nonzero bits is pass specific.
As a result we're limited in our ability to use the bset/bclr/binv
instructions.
Jeff
p; reloading, then convert that to a stack. The code in
reg-stack.c might help since it does basically the same thing for the
x86 FP unit.
But it's not a great fit for GCC in general.
Jeff
ion files.
I personally prefer to use binfmt handlers since it doesn't require any
dejagnu hackery and once the binfmt handlers are set up you can do so
much more than just run individual tests in the testsuite easily. For
example, if you have a RFS you can do full bootstraps rather than just
testing crosses.
jeff
last few
years I lost the password that allowed me to review this stuff. After
that it never bubbled up to get attention on my list.
jeff
u any
insights. The generator in that case is C, but it might give you a
structure to work within.
I'd also suggest wandering the aarch64 testsuite directory to see if
it's got anything generated (particular for builtin testing).
Jeff
Cheers,
Stefan
is was actually your proposal already. :-)
So, okay, unless someone fiercly objects in which case we need to have a
deeper conversation.
Yea, works for me as well. In an ideal world we really don't want users
mucking with --params, so moving them into the internals manual seems
like the right thing to do.
jeff
the compiler. Most likely it's not
finding a risc-v assembler.
jeff
uld be overcome with target hooks within the
contraints of the existing pass.
You might look at RISC-V's insertion of vsetvls which uses some of the
basic concepts from mode-switching, but is, umm, more complex.
jeff
e function. Then we let the standard mode
switching algorithm run.
For the cases that matter (and there are very very few with vxrm), that
gets us the desired speculation. While I could certainly construct a
testcase where the speculation was unprofitable, I doubt it ever happens
in practice.
jeff
nts of the existing pass.
In which case you might want to look at how RISC-V is handling vsetvl to
set the vector configuration. It's a target specific pass, but comes
closer to what you're doing. It's still LCM based, but deals with some
of the quirks of the RISC-V vector architecture.
Jeff
mode switching context.
Jeff
lly now that our uarch has been
fixed to not flush its pipelines at VXRM assignments ;-)
jeff
a patch over the wall for testing, happy to put it
into my tester and see what comes out the other side. I wouldn't be at
all surprised if it tripped on other targets.
jeff
their associated generation
step can take significant time.
jeff
On 8/8/24 6:26 AM, Stefan Schulze Frielinghaus wrote:
On Thu, Aug 08, 2024 at 06:03:13AM -0600, Jeff Law wrote:
On 8/8/24 5:15 AM, Stefan Schulze Frielinghaus via Gcc wrote:
However `(reg:DI 61 [ MEM[(const union T *)p_2(D)] ])` referencing the
same pseudo in a different mode is not
x_REG (reg_mode,
REGNO (lowpart)));
Yup, that's your problem I think. You can't create another instance of
the pseudo like that.
jeff
On 8/6/24 1:50 PM, Florian Weimer wrote:
* Jeff Law via Gcc:
On 8/5/24 4:23 PM, Mark Wielaard wrote:
It was suggested to just ignore the machine has rvv since it isn't
1.0
compliant. So it is now configured --with-arch=rv64gc --with-abi=lp64d
--with-multilib-list=lp64d but that d
ctor tests are still all run.
Quite possibly because the damn thing claims it's "V", but in fact it's
not compatible with the V1.0 spec. Sadly it's a common problem for
these V0.7.1 systems.
Jeff
On 7/24/24 11:25 AM, Artemiy Volkov wrote:
Hi Juzhe, Demin, Jeff,
This email is intended to continue the discussion started in
https://marc.info/?l=gcc-patches&m=170927452922009&w=2 about combining vfmv.v.f
and vfmxx.vv instructions into the scalar-vector form vfmxx.vf.
There was a
e point is that in some functions,
combine is almost exclusively producing these rtxes with clobber
const_int, but almost no meaningful combinations. Like in:
Perhaps, but the convention of using a (clobber (const_int 0)) for cases
where combine gets "lost" has been around for decades.
Jeff
from a security standpoint.
#3 isn't great, but it's not terrible either.
Jeff
rior to LRA and LRA needs to insert
any code, that inserted code may clobber the CC state. This is
discussed in the reload-to-LRA transition wiki page.
jeff
ts, but it can be made to work.
Jeff
On 6/4/24 8:51 PM, Erick Kuo-Chen Huang(黃國鎭) via Gcc-help wrote:
Hi,
We would like to know which GCC version start to support RISC-V RVV1.0 ?
We appreciate for your help.
gcc-14.
Jeff
the LRA conversion, getting a degree of stability in the
testsuite would be a huge step forward.
jeff
ky ABIs where direct and
indirect calls can have different calling conventions.
Jeff
On 5/21/24 8:02 AM, Paul Koning wrote:
On May 21, 2024, at 9:57 AM, Jeff Law wrote:
On 5/21/24 12:05 AM, Richard Biener via Gcc wrote:
On Mon, May 20, 2024 at 4:45 PM Gerald Pfeifer wrote:
On Wed, 5 Jul 2023, Joern Rennecke wrote:
I haven't worked with these targets in year
So a test which passes today, will flip to failing tomorrow
while some other test of tests will go the other way.
jeff
On 5/1/24 2:04 PM, Jason Merrill wrote:
On 5/1/24 12:15, Jeff Law wrote:
On 4/22/24 9:24 PM, Tom Tromey wrote:
Jason> Someone mentioned earlier that gerrit was previously tried
Jason> unsuccessfully.
We tried it and gdb and then abandoned it. We tried to integrate it
in
ternally. But boy I want to get away from email and to a
pull request kind of flow.
jeff
#x27;s been
fairly stable, but its not doing in-depth testing.
jeff
match.)
I've very much prefer to move to a pull-request model.
jeff
about the number and types of arguments.
Having said that, there is a GCC internals manual which describes the
RTL language, the format of backend patterns, expanders, etc. While the
vast majority will not be relevant to your effort, it is likely worth
bookmarking it for future reference.
jeff
rtainly measured in months
for an experienced GCC developer. Good luck.
jeff
before the deadline, but are still going through the review/iterate process.
Jeff
from including nds32.
jeff
, so I wouldn't lose any sleep if it
got deprecated across the board. While my tester includes nds32le-elf
and nds32be-elf, there's no gdbsim, so those targets don't provide much,
if any, additional coverage over targets in the tester.
Jeff
On 12/8/23 19:18, Alexandre Oliva wrote:
Hello, Jeff, DJ,
Thanks for the info.
On Dec 7, 2023, Jeff Law wrote:
On 12/6/23 15:03, DJ Delorie wrote:
Alexandre Oliva writes:
This looks like a latent bug in the port.
I'm not surprised, that port was weird.
This was just a plai
I suspect that something in the virt->phys logic just doesn't know how
to check for mem constraints in user asms.
I looked briefly, it appears the code just punts rewriting all user
asms, but maybe I missed something.
I wouldn't lose any sleep if we had a way to simply disable strub for rl78.
Jeff
ropping/converting during gimplification with a checker
that verifies they don't sneak back in. Then we can start to expunge
them from gimple passes. Feels like a gcc-15+ problem to me.
jeff
#x27;t useful at all
IMHO. Now you can get dynamic instructions from various QEMU plugins at
which point the data becomes much more interesting -- though you have to
be careful interpreting that as well.
Jeff
trying to port those changes over. Any
such effort would likely be better spent nailing down issues on the trunk.
jeff
re considering this behavior as a bug, I prefer to ask the community to
understand if there is any aspect I have missed in my reasoning.
It would help if you included the debugging dumps.
Jeff
d look to see the first pass where the condition gets removed
using -fdump-tree-all-details. That should give you strong hints about
what to look at next.
Conceptually something has determined that _2 never has the value 0
which through backwards propagation would indicate that __builtin_clz
never returns the value 32.
Jeff
uld be read only and cause a trap if written to. if the
branch is never taken there would be no writes
Right. See ifcvt_memrefs_wont_trap. That probably could be extended
to capture additional cases. But I'm not sure that'll be sufficient for
Hanke's problem.
Jeff
(of course) not given with a non-lto libgfortran.
Yea. This certainly can happen with LTO. These warnings would
definitely be something worth investigating.
Essentially the inlining enabled by LTO can expose a different set of
diagnostics.
Jeff
icit-function-declaration?
Jeff
to be limited to global ranges since
as you note, we're in a mixed IL state and ranger is probably going to
be confused as hell.
Jeff
ne_insn "return" ...)`.
Many ports define trivial returns. But it's much more common to need a
prologue and epilogue. Those are typically define_expands which
generate all the code to set up a stack frame and tear a stack frame
down+return.
Jeff
I am pleased to announce that the GCC Steering Committee has appointed
Ju-Zhe Zhong and Robin Dapp as reviewers for the RISC-V port.
Ju-Zhe and Robin, can you both updated your MAINTAINERS entry appropriately.
Thanks,
Jeff
instruction lengths.
Generally true, but not so on the m68k unless something significant has
changed.
On the m68k all this stuff is handled by the assembler.
jeff
king run to run
comparisons of the testsuite virtually impossible.
I did convert to LRA. But I didn't check to see if that brought
stability to the testsuite though.
jeff
regs which should give us some
chance at seeing the value reuse if/when IRA/LRA muck things up.
I'll be out of office for the rest of week, will look into this once I'm
back.
NP.
jeff
On 6/1/23 20:38, Vineet Gupta wrote:
Hi Jeff,
I finally got around to collecting various observations on PR/109279 -
more importantly the state of large constants in RV backend, apologies
in advance for the long email.
It seems the various commits in area have improved the original test
Sounds fine Thomas. Thanks.
-- Jeff J.
On Mon, May 15, 2023 at 4:01 AM Thomas Schwinge
wrote:
> Hi!
>
> On 2023-05-08T21:50:56+0200, I wrote:
> > Ping: OK to push to newlib main branch the attached
> > "For GCC, newlib combined tree, newlib build-tree testing, u
On 5/2/23 22:36, Varun Kumar E via Gcc wrote:
Hello,
https://godbolt.org/z/P3M8s8jqh
The above case shows that gcc first decreases the stack pointer and then
probes.
As mentioned by Jeff Law (reference
<https://developers.redhat.com/blog/2019/04/30/stack-clash-mitigation-in-gcc-why-fst
e we are
relative to the current gcc-13 bits. Doing an occasional forced update
isn't that bad (I've worked with this kind of flow for shared topic
branches in the past). But if you feel strongly, I can live with a
merge flow as well.
Jeff
hed to-date didn't seem important enough to
me to warrant porting to this branch. But if someone thinks otherwise,
I won't object to them being cherry-picked.
jeff
On 3/31/23 03:11, Vineet Gupta wrote:
Hi Jeff, Kito,
I need some ideas to proceed with PR/109279: pertaining to longer term
direction and short term fix.
First the executive summary:
long long f(void)
{
return 0x0101010101010101ull;
}
Up until gcc 12 this used to generate const pool
a trend in processor design to reduce/remove the
misalignment penalties (thus eliminating the driver for increasing data
alignment), that's been primarily in high end designs.
jeff
ime to fix before leaving Red Hat. We burn a fair amount of builder
time due to this issue right now.
jeff
nt to come back to GCC development, you'll
always be welcome Martin!
jeff
might know as well since I think they discussed it at
length a little while back.
jeff
e register isn't live at the
point where you want to do the insertion.
Or is that the core of the problem -- that life analysis is inaccurate
or unavailable?
Jeff
pect to safely shift them back in.
The semantics of a paradoxical subreg are that the bits outside the
inner mode are don't cares. Of course you *may* need to go back to a
compiler a that point in time to see the problematical case.
Jeff
and dies. So it's effectively a temporary. Combine
will re-use that temporary as the clobbered operand.
Jeff
to get this in earlier for GCC 13. It is literally a "do-nothing"
patch.
Just a note, I won't object if someone wants to move this forward.
jeff
ltiple hats, but it's not really
complicated. Each project makes a decision, by whatever means project
leadership has in place to make decisions. overseers then honors those
requests to stay or go. It's a pretty simple separation of
responsibilities. It need not be contentious in any way shape or form.
Jeff
ocked full migration of sourceware to LF IT.
They can make those decisions for the projects they lead. But making
the decision or setting criteria for other projects is highly unreasonable.
Jeff
LF IT, just say that. Don't
blame overseers.
Project leadership needs to make this decision. The sourceware
overseers should neither make the decision nor decide how high the bar
needs to be for any given project.
Jeff
On 10/19/22 01:46, Richard Biener wrote:
On Wed, Oct 19, 2022 at 5:44 AM Jeff Law via Gcc wrote:
On 10/18/22 20:09, Vineet Gupta wrote:
On 10/18/22 16:36, Jeff Law wrote:
There isn't a great place in GCC to handle this right now. If the
constraints were relaxed in PRE, then we
On 10/18/22 20:09, Vineet Gupta wrote:
On 10/18/22 16:36, Jeff Law wrote:
There isn't a great place in GCC to handle this right now. If the
constraints were relaxed in PRE, then we'd have a chance, but
getting the cost model right is going to be tough.
It would have been better
gimple, but never was able to
convince myself the implementation was correct or that integrating it
was a good thing. It's almost certainly going to cause performance
regressions elsewhere so it may end up doing more harm than good. I
don't really know.
https://courses.cs.washington.edu/courses/cse501/06wi/reading/click-pldi95.pdf
Jeff
x27;t place an eval in BB2 because that
will cause evaluations on 2->4->6 which didn't have any evaluations.
There isn't a great place in GCC to handle this right now. If the
constraints were relaxed in PRE, then we'd have a chance, but getting
the cost model right is going to be tough.
Jeff
ature optimization) and probably just an oversight thinking
that a block with no real insns could be totally ignored.
jeff
On 4/28/2022 9:29 AM, Jakub Jelinek wrote:
On Thu, Apr 28, 2022 at 09:25:43AM -0600, Jeff Law via Gcc wrote:
On 4/28/2022 8:59 AM, Jakub Jelinek via Gcc wrote:
Status
==
We have reached zero P1 regressions today and releases/gcc-12 branch has
been created. GCC 12.1-rc1 will be built
validation of a couple targets in my tester which completed yesterday.
Jeff
On 4/25/2022 8:37 AM, Jeff Law wrote:
On 4/25/2022 6:56 AM, Martin Liška wrote:
I used -z execstack rather than --no-warn-execstack as the former is
recognized by older versions of ld, but the latter is a new option.
Thanks for it.
Unfortunately, I should have looked at the other
On 4/25/2022 9:26 AM, Nick Clifton wrote:
Hi Jeff,
Just FYI - I am also looking at adding in another warning. This
time for
when the linker creates a PT_LOAD segment which has all of the RWX
flags
set. At the moment my testing seems to show that it only causes
problems
when a
On 4/25/2022 8:42 AM, Nick Clifton wrote:
Hi Jeff,
I used -z execstack rather than --no-warn-execstack as the former
is recognized by older versions of ld, but the latter is a new option.
Thanks for it.
Unfortunately, I should have looked at the other failures that have
popped up over the
week. Essentially all the nested function tests
are failing on some targets due to the same linker warning.
Either pruning or adding the option to all those tests is going to be
necessary ;(
jeff
etter since we'd like most tests to fail if somehow their stacks were
executable.
Committed to the trunk.
Jeff
commit 6b7441a46c771aa6ecdc0c8ed96197417d036b9a
Author: Jeff Law
Date: Sun Apr 24 13:38:14 2022 -0400
[committed] exec-stack warning for test which wants executa
e (I don' t have
the # handy, but it's probably on the Wuninitialized tracker).
Jeff
ut of registers on all of them. The key property
is the size/alignment of the argument differs depending on if it's pass
in a register (get promoted) or passed in memory (not promoted). I'm
not immediately aware of another ABI with that feature. Though I
haven't really gone looking.
jeff
On 1/7/2022 7:49 AM, Jeff Law wrote:
On 1/7/2022 3:25 AM, Martin Jambor wrote:
Hi,
Would anyone be terribly against mass renaming all *.c files (that are
actually C++ files) within the gcc subdirectory to ones with .cc suffix?
We already have 47 files with suffix .cc directly in the gcc
gets released but see
little value in doing so.
What do others think? (Any important caveats I might have missed?)
I think it's well past time we do this. There may be a bit of pain
with cherry-picking across the rename point, but we should just deal
with it.
jeff
On 11/24/2021 12:41 PM, Zdenek Sojka wrote:
Hello Jeff,
-- Původní e-mail --
Od: Jeff Law via Gcc
Komu: Paul Floyd , gcc@gcc.gnu.org
Datum: 24. 11. 2021 20:33:02
Předmět: Re: distinguishing gcc compilation valgrind false positives
On 11/24/2021 12:15 PM, Paul Floyd
e triggering that you do not
want to trigger.
Could we think of the optimization opportunity in a different way?
(A << B) eq/ne 0 -> A eq/ne (0U >> B)
And I would expect the 0U >> B to get simplified to 0.
Would looking at things that way help?
jeff
e are the only ones I would consistently ignore from
GCC.
Jeff
but this
case is simple enough that we don't need to query the target's
capabilities, look at stack usage, worry about argument mappings, etc.
jeff
ments which exist merely to compute the conditional we
thread are going to be removed and we need not worry about the cost of
copying them which allowed us to thread many cases we had missed before
without increasing codesize.
Anyway, those are the research areas to look at first, then we'll figure
out what the next steps are.
JEff
nstall/prerequisites.html
to s/1.4.4/1.5.3/g && git commit -m 'bump dejagnu required version' ?
All kinds of people. Submit a patch and I bet it'll get approved. More
than anything I suspect it's out-of-sight-out-of-mind at this point
holding us back.
jeff
On 9/27/2021 7:52 AM, Aldy Hernandez wrote:
[CCing Jeff and list for broader audience]
On 9/27/21 2:53 PM, Maxim Kuvyrkov wrote:
Hi Aldy,
Your patch seems to slow down 471.omnetpp by 8% at -O3. Could you
please take a look if this is something that could be easily fixed?
First of all
On 9/10/2021 10:05 AM, Aldy Hernandez wrote:
On 9/10/21 5:43 PM, Jeff Law wrote:
On 9/9/2021 3:21 AM, Aldy Hernandez wrote:
/* If this path does not thread through the loop latch, then we are
using the FSM threader to find old style jump threads. This
is good, except
end
of its useful life. FRE has a lot more going for it.
But the same way DOM can register jump threading opportunities FRE
could do as well.
I'd advise against that and instead look towards a model where no pass
has integrated jump threading and the only jump threading module we have
is the backwards threader.
jeff
dity/costing metrics
and thus
classify threading opportunities in a different way?
Jeff, do you have any insight here?
This is precisely what you're cleaning up.
I think today "backwards" vs, "forwards" only refers to the way we find
threading opportunities.
simple. The backwards threader uses a different block
copier and CFG update mechanism that does not support commonizing
threads from multiple paths to the same target. So each jump thread
ends up with a copy of the path which can lead to excessive code bloat.
THe forward threader knows how to commonize those paths so cut down on
the duplicates and thus can accept larger blocks without having such a
negative impact on code size.
I think today "backwards" vs, "forwards" only refers to the way we find
threading opportunities.
Correct.
jeff
1 - 100 of 1421 matches
Mail list logo
