Is ther document that describes how the "braching/fixing" on releases is done
GCC 7.5 November 14, 2019 GCC 9.2 August 12, 2019 GCC 9.1 May 3, 2019 GCC 8.3 February 22, 2019 GCC 7.4 December 6, 2018 GCC 6.5 October 26, 2018 GCC 8.2 July 26, 2018 GCC 8.1 May 2, 2018 GCC 7.3 January 25, 2018 GCC 5.5 October 10, 2017 GCC 7.2 August 14, 2017 GCC 6.4 July 4, 2017 GCC 7.1 May 2, 2017 GCC 6.3 December 21, 2016 for example: is the 6.4 release only a bug fix "branch" of the 6.3 "branch" and the real succesor of 6.3 is 7.1? and sucessor of 7.3 is 8.1?
Re: Is ther document that describes how the "braching/fixing" on releases is done
On Sun, Feb 16, 2020 at 11:36 AM Dennis Luehring wrote: > > GCC 7.5 November 14, 2019 > GCC 9.2 August 12, 2019 > GCC 9.1 May 3, 2019 > GCC 8.3 February 22, 2019 > GCC 7.4 December 6, 2018 > GCC 6.5 October 26, 2018 > GCC 8.2 July 26, 2018 > GCC 8.1 May 2, 2018 > GCC 7.3 January 25, 2018 > GCC 5.5 October 10, 2017 > GCC 7.2 August 14, 2017 > GCC 6.4 July 4, 2017 > GCC 7.1 May 2, 2017 > GCC 6.3 December 21, 2016 > > for example: > > is the 6.4 release only a bug fix "branch" of the 6.3 "branch" > > and the real succesor of 6.3 is 7.1? and sucessor of 7.3 is 8.1? https://gcc.gnu.org/develop.html#timeline - David
Re: Is ther document that describes how the "braching/fixing" on releases is done
Am 16.02.2020 um 18:03 schrieb David Edelsohn: https://gcc.gnu.org/develop.html#timeline Thanks any idea how to reintegrate (many) changes from a release/6.3.0 branch back into mainline? is there a tag or something where mainline was for short time in sync with 6.3.0?
Re: Is ther document that describes how the "braching/fixing" on releases is done
On Sun, Feb 16, 2020 at 12:19 PM Dennis Luehring wrote: > > Am 16.02.2020 um 18:03 schrieb David Edelsohn: > > https://gcc.gnu.org/develop.html#timeline > > > Thanks > > any idea how to reintegrate (many) changes from a release/6.3.0 branch > back into mainline? > > is there a tag or something where mainline was for short time in sync > with 6.3.0? There is no need to reintegrate changes from a release into trunk. The intent is that all bugs are fixed on trunk and back-ported to branches. The fix on a release branch may be implemented differently or as a work-around, but the bug is intended to be fixed in all release branches that still are maintained, where the bug is relevant, that exhibited the bug and where the benefit justifies the potential risk of the bug fix. Thanks David
Re: Is ther document that describes how the "braching/fixing" on releases is done
Am 16.02.2020 um 18:27 schrieb David Edelsohn: On Sun, Feb 16, 2020 at 12:19 PM Dennis Luehring wrote: > > Am 16.02.2020 um 18:03 schrieb David Edelsohn: > > https://gcc.gnu.org/develop.html#timeline > > > Thanks > > any idea how to reintegrate (many) changes from a release/6.3.0 branch > back into mainline? > > is there a tag or something where mainline was for short time in sync > with 6.3.0? There is no need to reintegrate changes from a release into trunk. The intent is that all bugs are fixed on trunk and back-ported to branches. The fix on a release branch may be implemented differently or as a work-around, but the bug is intended to be fixed in all release branches that still are maintained, where the bug is relevant, that exhibited the bug and where the benefit justifies the potential risk of the bug fix. Thanks David i've got an older project where features where integrated based on an 6.3.0 branch no bug fixes - only new features and no backporting was done :( i now want to reintegrate these new features back into mainline (not directly into head due to amount conflicts) but somewhere around "GCC 7 Stage 4 (starts 2017-01-20)" could work i think or should i try to directly merge with a 7.1 tag branch, i've no idea how many changes where done
Re: Is ther document that describes how the "braching/fixing" on releases is done
On Sun, Feb 16, 2020 at 12:36 PM Dennis Luehring wrote: > > Am 16.02.2020 um 18:27 schrieb David Edelsohn: > > On Sun, Feb 16, 2020 at 12:19 PM Dennis Luehring wrote: > > > > > > Am 16.02.2020 um 18:03 schrieb David Edelsohn: > > > > https://gcc.gnu.org/develop.html#timeline > > > > > > > Thanks > > > > > > any idea how to reintegrate (many) changes from a release/6.3.0 branch > > > back into mainline? > > > > > > is there a tag or something where mainline was for short time in sync > > > with 6.3.0? > > > > There is no need to reintegrate changes from a release into trunk. > > The intent is that all bugs are fixed on trunk and back-ported to > > branches. The fix on a release branch may be implemented differently > > or as a work-around, but the bug is intended to be fixed in all > > release branches that still are maintained, where the bug is relevant, > > that exhibited the bug and where the benefit justifies the potential > > risk of the bug fix. > > > > Thanks David > > > i've got an older project where features where integrated based on an > 6.3.0 branch > > no bug fixes - only new features and no backporting was done :( > > > i now want to reintegrate these new features back into mainline (not > directly into head due to amount conflicts) > > but somewhere around "GCC 7 Stage 4 (starts 2017-01-20)" could work i think > > or should i try to directly merge with a 7.1 tag branch, i've no idea > how many changes where done If you are trying to forward-port your own, proprietary features into a newer release of GCC for your own, internal use, that's your responsibility. If you wish to contribute new features to FSF GCC, they only will be accepted into trunk. You would need to integrate the feature into trunk and propose patches relative to trunk during Stage 1 development. New features are not back-ported to FSF GCC release branches. Thanks David
Re: Is ther document that describes how the "braching/fixing" on releases is done
Am 16.02.2020 um 18:42 schrieb David Edelsohn: If you are trying to forward-port your own, proprietary features into a newer release of GCC for your own, internal use, that's your responsibility. that is my case, i ask for a meaningfull way of doing that i could upgrade the 6.3 branch to 6.4, 6.5 and then try to merge back into a branch based on releases/gcc-7.1.0 or try to directly merge the 6.3 with a releases/gcc-7.1 tag based branch, what would be easier?
Re: Matching and testing against smulhsm3
On 2020-02-09 19:02, Segher Boessenkool wrote:
On Sun, Feb 09, 2020 at 12:15:03PM +0100, m wrote:
On 2020-02-07 16:44, Segher Boessenkool wrote:
(define_insn "smulhshi3"
[(set (match_operand:HI 0 "register_operand" "=r")
(truncate:HI
(ashiftrt:SI
(mult:SI
(sign_extend:SI (match_operand:HI 1
"register_operand" "r"))
(sign_extend:SI (match_operand:HI 2
"register_operand" "r")))
(const_int 15]
"TARGET_PACKED_OPS"
"mulq.h\\t%0, %1, %2")
However, I am unable to trigger this code path. I have tried with the
following C code:
short mulq(short op1, short op2) {
return (short) (((int) op1 * (int) op2) >> (32 / 2 - 1));
}
But I just get the regular 4-instruction result (2x sign extend, 1x mul,
1x shift).
What does -fdump-rtl-combine-all show it tried? *Did* it try anything?
Cool option. I'm not really sure how to read the output tough. The
closest it seems to try to match is this:
For every combination tried, it shows "Trying 2 -> 6:" etc., followed by
the instructions it started with (which is very important), and then
what worked and what didn't, and more debug information.
I usually need to see that whole block (everything until the next
"Trying:").
I've attached the full output of -fdump-rtl-combine-all.
Failed to match this instruction:
(set (reg:SI 85)
(ashiftrt:SI (mult:SI (sign_extend:SI (subreg:HI (reg:SI 86) 0))
(reg:SI 83 [ op2D.1381 ]))
(const_int 15 [0xf])))
It seems that it has already decided to split the instruction into
several operations (the truncate operation is not there, and the second
sign_extend:SI (subreg:HI ...) is also missing).
The code probably sign-extends the result; I need to see the full thing
to really know. Similarly, the sign_extend of a const_int is not
canonical rtl, it always is written as just a const_int.
You'll probably need to write a few extra patterns to recognise all the
options here.
I haven't had much time to dig more into this, but I hope to do so soon.
Regards,
Marcus
;; Function mulq (mulq, funcdef_no=0, decl_uid=1382, cgraph_uid=1,
symbol_order=0)
Pass statistics of "combine":
scanning new insn with uid = 21.
rescanning insn with uid = 2.
scanning new insn with uid = 22.
rescanning insn with uid = 4.
starting the processing of deferred insns
ending the processing of deferred insns
df_analyze called
df_worklist_dataflow_doublequeue: n_basic_blocks 3 n_edges 2 count 3 (1)
mulq
Dataflow summary:
def_info->table_size = 20, use_info->table_size = 18
;; fully invalidated by EH 1 [s1] 2 [s2] 3 [s3] 4 [s4] 5 [s5] 6 [s6] 7
[s7] 8 [s8] 9 [s9] 10 [s10] 11 [s11] 12 [s12] 13 [s13] 14 [s14]
;; hardware regs used 28 [sp] 64 [?fp] 65 [?ap]
;; regular block artificial uses26 [fp] 28 [sp] 64 [?fp] 65 [?ap]
;; eh block artificial uses 26 [fp] 28 [sp] 64 [?fp] 65 [?ap]
;; entry block defs 1 [s1] 2 [s2] 3 [s3] 4 [s4] 5 [s5] 6 [s6] 7 [s7] 8
[s8] 26 [fp] 28 [sp] 30 [lr] 64 [?fp] 65 [?ap]
;; exit block uses 1 [s1] 26 [fp] 28 [sp] 30 [lr] 64 [?fp]
;; regs ever live 1 [s1] 2 [s2]
;; ref usage r1={2d,3u} r2={1d,1u} r3={1d} r4={1d} r5={1d} r6={1d} r7={1d}
r8={1d} r26={1d,2u} r28={1d,2u} r30={1d,1u} r64={1d,2u} r65={1d,1u} r78={1d,1u}
r80={1d,1u} r82={1d,1u} r83={1d,1u} r84={1d,1u} r85={1d,1u} r86={1d,1u}
r87={1d,1u}
;;total ref usage 42{22d,20u,0e} in 10{10 regular + 0 call} insns.
( )->[0]->( 2 )
;; bb 0 artificial_defs: { d1(1){ }d2(2){ }d3(3){ }d4(4){ }d5(5){ }d6(6){
}d7(7){ }d8(8){ }d9(26){ }d10(28){ }d11(30){ }d12(64){ }d13(65){ }}
;; bb 0 artificial_uses: { }
;; lr in
;; lr use
;; lr def 1 [s1] 2 [s2] 3 [s3] 4 [s4] 5 [s5] 6 [s6] 7 [s7] 8 [s8] 26
[fp] 28 [sp] 30 [lr] 64 [?fp] 65 [?ap]
;; live in
;; live gen 1 [s1] 2 [s2] 3 [s3] 4 [s4] 5 [s5] 6 [s6] 7 [s7] 8 [s8] 26
[fp] 28 [sp] 30 [lr] 64 [?fp] 65 [?ap]
;; live kill
;; lr out 1 [s1] 2 [s2] 26 [fp] 28 [sp] 30 [lr] 64 [?fp] 65 [?ap]
;; live out 1 [s1] 2 [s2] 26 [fp] 28 [sp] 30 [lr] 64 [?fp] 65 [?ap]
( 0 )->[2]->( 1 )
;; bb 2 artificial_defs: { }
;; bb 2 artificial_uses: { u0(26){ }u1(28){ }u2(64){ }u3(65){ }}
;; lr in1 [s1] 2 [s2] 26 [fp] 28 [sp] 30 [lr] 64 [?fp] 65 [?ap]
;; lr use 1 [s1] 2 [s2] 26 [fp] 28 [sp] 64 [?fp] 65 [?ap]
;; lr def 1 [s1] 78 80 82 83 84 85 86 87
;; live in 1 [s1] 2 [s2] 26 [fp] 28 [sp] 30 [lr] 64 [?fp] 65 [?ap]
;; live gen 1 [s1] 78 80 82 83 84 85
;; live kill
;; lr out 1 [s1] 26 [fp] 28 [sp] 30 [lr] 64 [?fp] 65 [?ap]
;; live out 1 [s1] 26 [fp] 28 [sp] 30 [lr] 64 [?fp] 65 [?ap]
( 2 )->[1]->( )
;; bb 1 artificial_defs: { }
;; bb 1 artificial_uses: { u13(1){ }u14(26){ }u15(28){ }u16(30){ }u17(64){ }}
;; lr in1 [s1] 26 [fp] 28 [sp] 30 [lr] 64 [?fp]
;; lr use 1 [s1] 26 [fp] 28 [sp] 30 [lr] 64 [?fp]
;; lr def
;; live in 1 [s1] 26 [fp] 28 [sp] 30 [lr] 64 [?fp]
;; live
gcc-10-20200216 is now available
Snapshot gcc-10-20200216 is now available on https://gcc.gnu.org/pub/gcc/snapshots/10-20200216/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 10 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch master revision 6e37e49616d429c5d922324ebd72ae95f12a079f You'll find: gcc-10-20200216.tar.xz Complete GCC SHA256=f7f129d4884eb9f7173018be2188c76e1f4bf0795a79c244cf6b6964e153961d SHA1=434d1c0e9de871ee26f7585a578c247dc1d92f48 Diffs from 10-20200209 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-10 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Matching and testing against smulhsm3
Hi! On Sun, Feb 16, 2020 at 09:52:12PM +0100, Marcus Geelnard wrote: > (define_insn "smulhshi3" > [(set (match_operand:HI 0 "register_operand" "=r") > (truncate:HI > (ashiftrt:SI > (mult:SI > (sign_extend:SI (match_operand:HI 1 "register_operand" "r")) > (sign_extend:SI (match_operand:HI 2 "register_operand" "r"))) > (const_int 15] > "TARGET_PACKED_OPS" > "mulq.h\\t%0, %1, %2") > insn_cost 4 for21: r86:SI=s1:SI > REG_DEAD s1:SI > insn_cost 4 for 2: r78:SI=r86:SI > REG_DEAD r86:SI > insn_cost 4 for22: r87:SI=s2:SI > REG_DEAD s2:SI > insn_cost 4 for 4: r80:SI=r87:SI > REG_DEAD r87:SI > insn_cost 4 for 9: r82:SI=sign_extend(r78:SI#0) > REG_DEAD r78:SI > insn_cost 4 for10: r83:SI=sign_extend(r80:SI#0) > REG_DEAD r80:SI > insn_cost 20 for11: r84:SI=r82:SI*r83:SI > REG_DEAD r83:SI > REG_DEAD r82:SI > insn_cost 8 for12: r85:SI=r84:SI>>0xf > REG_DEAD r84:SI > insn_cost 4 for18: s1:HI=r85:SI#0 > REG_DEAD r85:SI > insn_cost 0 for19: use s1:HI 21 and 22 remain like this, so that register allocation can use whatever registers work best here. > Trying 2 -> 9: > Successfully matched this instruction: > Trying 4 -> 10: > Successfully matched this instruction: As expected here. > Trying 9 -> 11: > Failed to match this instruction: > (set (reg:SI 84) > (mult:SI (sign_extend:SI (subreg:HI (reg:SI 86) 0)) > (reg:SI 83 [ op2D.1381 ]))) > > Trying 10 -> 11: > Failed to match this instruction: > (set (reg:SI 84) > (mult:SI (sign_extend:SI (subreg:HI (reg:SI 87) 0)) > (reg:SI 82 [ op1D.1380 ]))) Neither sign_extend combines with the mult on its own. > Trying 10, 9 -> 11: > Failed to match this instruction: > (set (reg:SI 84) > (mult:SI (sign_extend:SI (subreg:HI (reg:SI 87) 0)) > (sign_extend:SI (subreg:HI (reg:SI 86) 0 And neither do both together. Do you have an instruction that can do this? How expensive is it? > Trying 11 -> 12: >11: r84:SI=r82:SI*r83:SI > REG_DEAD r83:SI > REG_DEAD r82:SI >12: r85:SI=r84:SI>>0xf > REG_DEAD r84:SI > Failed to match this instruction: > (set (reg:SI 85) > (ashiftrt:SI (mult:SI (reg:SI 82 [ op1D.1380 ]) > (reg:SI 83 [ op2D.1381 ])) > (const_int 15 [0xf]))) Good ;-) > Trying 9, 11 -> 12: > Failed to match this instruction: > (set (reg:SI 85) > (ashiftrt:SI (mult:SI (sign_extend:SI (subreg:HI (reg:SI 86) 0)) > (reg:SI 83 [ op2D.1381 ])) > (const_int 15 [0xf]))) > Trying 10, 11 -> 12: > Failed to match this instruction: > (set (reg:SI 85) > (ashiftrt:SI (mult:SI (sign_extend:SI (subreg:HI (reg:SI 87) 0)) > (reg:SI 82 [ op1D.1380 ])) > (const_int 15 [0xf]))) Neither of those work, that is fine as well. But, 9+10+11+12 is not tried. See https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/combine.c;h=d44b9c3bf950e52dce5089f7297a9fc7fb28dcfd;hb=HEAD#l2728 for why we don't here: most 4-insn combinations (where no 3-insn subset of it leads to a valid insn) do not go anywhere, and there are *many* such combinations that can be tried. Instructions with a binary op with a constant source count as one "ngood", and instructions that are just a move from a constant into something count as two "ngood". Shifts are counted separately, in "nshift". So here we get ngood=0 and nshift=1, but we need one of them to be at least 2 to try a 4-insn combo. Maybe we should have an "nextend" as well? Many targets use something like this for widening multiplies. I'll try something like that, but it won't make it into GCC 10 (we're in development stage 4 for it now). In the meantime, you can add a pattern for the result of 9+10+11: (set (match_operand:SI ...) (mult:SI (sign_extend:SI (match_operand:HI ...)) (sign_extend:SI (match_operand:HI ... (which you then have to handle, of course, either with a machine insn if that exists, or some other way, a libcall perhaps; you already have some way to do mulsi3 I guess?) Segher
