RE: On pull request workflows for the GNU toolchain
> From: Joseph Myers > Sent: Wednesday, September 25, 2024 10:46 PM > > On Wed, 25 Sep 2024, Jiang, Haochen via Gcc wrote: > > > The potential issue might be the PR will be closed after merging, which > > might > > be flooded in history if the regression is not fixed with the PR forgotten > > to be > > reopened. I am not sure the reopen could be automatically done. If it could, > > I think reopening is for when a PR was reverted after being merged; not > for when a regression was found but is going to be addressed through > subsequent fix commits rather than through reverting. You might want to > file a bug in Bugzilla for the regression (automatically or otherwise), > however. I will have a try on that when I have some time. Maybe in GCC stage 3 I suppose since I plan to go through the current regressions to see if it is fixed and the regression framework to see if it can improve at that time. Thx, Haochen > > -- > Joseph S. Myers > josmy...@redhat.com
Re: [RFC] Return Value Propagation in IPA-CP
On 15/09/24 18:04, Jan Hubicka wrote:
External email: Use caution opening links or attachments
Ping (https://gcc.gnu.org/pipermail/gcc/2024-August/244625.html).
Hi,
Hi,
Thanks for the feedback! A few comments:
* Proposed Solution *
* Extending IPA-CP:
1. Add return jump function data structures
- This involves updating ipa_node_params to contain information regarding
the
return statements of the function, namely the lattice and the jump
function
describing the return value, where both use existing data structures.
- The ipa_node_params class is reused to avoid introducing a new class and a
corresponding function_summary type, though it is trivial to add if deemed
a better solution. The ipa_return_value_summary class may also be a good
place for this information, however using it would involve moving it from
ipa-prop.cc to ipa-prop.h.
Yes, I think the jump functions for return values are not realy
different from jump functions for call parameters, so indeed we want to
reuse same datatstructure.
We want to track all the usual stuff we do (value ranges, constant
values, known fields in structures...)
In longer run we will want to extend jump functions to represent
properties like "value returned by call X is passed as argument n to
call Y". But for the first version we probably do not need to worry
about this.
- Additionally, ipa_edge_args is updated to track whether or not it is a
callgraph edge originating from a return statement. This enables the
propagation of information in the WPA phase.
What you exactly mean by callgraph edge originating from return
statement?
As a first step, there are three main types of expressions in return statements
we are analyzing:
- Direct returns of formal parameters
- PHI nodes (which can be nested/recursive)
- Call expressions (this is the information we are propagating in ipa-cp)
For the first version of our patch, we are using ipa-cp as a framework only for
analysis and propagation, not for transformations. So, we are detecting
candidates for attribution with "returns_arg", and propagating that information
from callee to caller in ipa-cp in the hopes that we can annotate callers as
well by using the information from the callee.
This is why we need to detect when a callgraph edge "originates" from a return
statement, so that we know which callees to propagate to callers from. We are
interested in walking from callees to callers, so this allows us to effectively
do that.
Consider the following example:
int foo (int x) { return x; }/* <- foo becomes returns_arg (1) */
int bar (int x) { return foo (x); }
In this example, bar calls foo in a return statement so the edge from bar to foo
becomes a "return edge". This allows us to propagate "returns_arg" information
from foo to bar, so we are able to annotate bar as well.
2. LGEN
- Set up return jump functions for each function similar to the parameter
jump function. When it cannot be conclusively determined that one formal
parameter is always returned (such as conditionally returning either of
two), the jump function is marked as invalid.
- This involves looking through phi nodes when return statements of
conditional branches are merged into a single exit block. Note that
returning a call expression does not count towards invalidating the
information for that function.
The analysis is essentially the same as for function parameters, just
looking at the return statements, so I think most of code can be shared
with what we have.
3. WPA
- Implement return value information propagation. It is not possible to do
this in the existing propagate_constants_topo function, because it
iterates
in reverse postorder i.e. from caller to callee. However return value
propagation needs to be done from callee to caller, thus there is a need
to
iterate in a postorder fashion.
- The lattice values are initialized using the jump functions computed in
the
LGEN phase. These values are then propagated over the callgraph.
- The existing lattices are reused, with three possible values like usual.
The possible values are:
return_lattice -> { TOP, param_decl, BOTTOM }
where TOP and BOTTOM are defined as usual. param_decl refers to the tree
of
either the parameter declaration or its type, whichever is available. The
meet operator is defined as usual for TOP and BOTTOM. When both are
param_decl, the following meet operation is defined:
meet(x, y) = x if x == y, BOTTOM otherwise
- Finally, nodes to which no information could be propagated are marked as
BOTTOM and the BOTTOM value is propagated to a fixed-point. This is
required
when information about a caller has been inferred but not about one of its
callees. For example:
extern int foo(int);
__attribute__((noinline))
int bar (int z
The riscv compilation chain for your own operating system cannot recognize march.
Hi everyone, I'm new to the world of gcc. I don't know if this is the right place to post, but I'm having some issues that are really annoying. I've created a Unix-like system, and although it's not very complete yet, I want to make a cross-compilation chain for it so that I can use some open source c libraries. I modify these files: config.sub, fixincludes/mkfixinc.sh, config.gcc, gcc/config/caffeinix.h, libgcc/config.host But after I compiled gcc, I ran into problems when I ran it. I tried to compile a test file (it has nothing but the main function), but I got the following error: ❯ ./riscv64-caffeinix-gcc -o test test.c Assembler messages: Fatal error: invalid -march= option: `rv64imafdc_zicsr' Information I can provide: Host: Ubuntu 22.04 Newlib (compiled by myself): 2.5.0 And the compiled gcc information: ❯ ./riscv64-caffeinix-gcc -march=rv64gc -Q --help=target The following options are target specific: -mabi= lp64d -malign-data= xlen -march= rv64imafdc_zicsr_zifencei -mbig-endian [disable] -mbranch-cost=N 3 -mcmodel= medlow -mcpu=PROCESSOR -mcsr-check [disable] -mdiv [enable] -mexplicit-relocs [enable] -mfdiv [enable] -minline-atomics [enable] -misa-spec= 20191213 -mlittle-endian [enable] -mplt [enable] -mpreferred-stack-boundary= 0 -mrelax [enable] -mriscv-attribute [enable] -msave-restore [disable] -mshorten-memrefs [enable] -msmall-data-limit=N 8 -mstack-protector-guard-offset= -mstack-protector-guard-reg= -mstack-protector-guard= global -mstrict-align [enable] -mtune=PROCESSOR rocket Supported ABIs (for use with the -mabi= option): ilp32 ilp32d ilp32e ilp32f lp64 lp64d lp64f Known encoding models (for use with the -mcmodel= option): medany medlow Supported ISA specs (for use with the -misa-spec= option): 2.2 20190608 20191213 Known data alignment choices (for use with the -malign-data= option): natural xlen Valid arguments to -mstack-protector-guard=: global tls Known valid arguments for -mcpu= option: sifive-e20 sifive-e21 sifive-e24 sifive-e31 sifive-e34 sifive-e76 sifive-s21 sifive-s51 sifive-s54 sifive-s76 sifive-u54 sifive-u74 thead-c90 6 Known valid arguments for -mtune= option: rocket sifive-3-series sifive-5-series sifive-7-series thead-c906 size sifive-e20 sifive-e21 sifive-e24 sifive-e31 sifive-e34 sifive-e76 sifive-s21 sifive-s51 sifive-s54 sifive-s76 sifive-u54 sifive-u74 thead-c906 Assembler messages: Fatal error: invalid -march= option: `rv64gc' ❯ ./riscv64-caffeinix-gcc -v Using built-in specs. COLLECT_GCC=./riscv64-caffeinix-gcc COLLECT_LTO_WRAPPER=/home/troy/repo/riscv-toolchain/riscv-gnu-toolchain/bin-gcc/libexec/gcc/riscv64-caffeinix/13.2.0/lto-wrapper target: riscv64-caffeinix configured as: ../gcc/configure --target=ris cv64-caffeinix --prefix=/home/troy/repo/riscv-toolchain/riscv-gnu-toolchain/bin-gcc/ --with-sysroot=/home/troy/repo/riscv-toolchain/bin-newlib/ --enable-languages=c --with-headers=/home/troy/repo/riscv-toolchain/bin-newlib/riscv64-caffeinix/include --with-arch=rv64imafdc --with-abi=lp64d --with-tune=rocket --with-isa-spec=20191213 --with-newlib Threading model: single Supported LTO compression algorithm: zlib gcc version 13.2.0 (GCC) Thanks for any response and help! Best regards. Troy.
Re: The riscv compilation chain for your own operating system cannot recognize march.
On 9/25/24 2:56 AM, Troy Mitchell via Gcc wrote: Hi everyone, I'm new to the world of gcc. I don't know if this is the right place to post, but I'm having some issues that are really annoying. I've created a Unix-like system, and although it's not very complete yet, I want to make a cross-compilation chain for it so that I can use some open source c libraries. I modify these files: config.sub, fixincludes/mkfixinc.sh, config.gcc, gcc/config/caffeinix.h, libgcc/config.host But after I compiled gcc, I ran into problems when I ran it. I tried to compile a test file (it has nothing but the main function), but I got the following error: ❯ ./riscv64-caffeinix-gcc -o test test.c Assembler messages: Fatal error: invalid -march= option: `rv64imafdc_zicsr' Information I can provide: Host: Ubuntu 22.04 Newlib (compiled by myself): 2.5.0 And the compiled gcc information: ❯ ./riscv64-caffeinix-gcc -march=rv64gc -Q --help=target [ ... ] Assembler messages: Fatal error: invalid -march= option: `rv64gc' ❯ ./riscv64-caffeinix-gcc -v More important would be to see the -v output when you ran the compiler and got the error message from the compiler. Most likely it's not finding a risc-v assembler. jeff
RE: On pull request workflows for the GNU toolchain
On Wed, 25 Sep 2024, Jiang, Haochen via Gcc wrote: > The potential issue might be the PR will be closed after merging, which might > be flooded in history if the regression is not fixed with the PR forgotten to > be > reopened. I am not sure the reopen could be automatically done. If it could, I think reopening is for when a PR was reverted after being merged; not for when a regression was found but is going to be addressed through subsequent fix commits rather than through reverting. You might want to file a bug in Bugzilla for the regression (automatically or otherwise), however. -- Joseph S. Myers josmy...@redhat.com
