Fiberglass Sleevings & Heat Shrink Tubes

[Ms Pooja 8928403615]

Fiberglass Sleevings & Heat Shrink Tubes

[Ms Pooja 8928403615]

Re: Expansion of narrowing math built-ins into power instructions

[Tejas Joshi]

Hello.

> For ISA 2.07 (Power 8) you don't have IEEE128 at all, not in hardware
> that is.  I don't know if we'll want fadd support in the emulation
> libraries ever; don't worry about it for now, anyway.

What instructions would need to be expanded for FADDL (long double to
float) and DADDL (long double to double) on power8 (ISA 2.07) and
power9 (ISA 3.0) respectively, along with VSX? (Just as we expanded
FADD to fadds and xsaddsp for vsx).

Thanks,
Tejas


On Mon, 26 Aug 2019 at 13:12, Segher Boessenkool
 wrote:
>
> > > [ Please don't top-post ]
>
> On Mon, Aug 26, 2019 at 12:43:44PM +0530, Tejas Joshi wrote:
> > Sorry for not being clear. I am confused about some modes here. I
> > meant, just as we expanded fadd (which narrows down from double to
> > float) with add_truncdfsf3, how can I expand faddl (which narrows down
> > long double to float). Wouldn't I require TFmode -> SFmode as
> > add_trunctfsf3 just as Joseph had previously mentioned?
>
> Yes, you need an addsfkf2 as well as adddfkf2 (and tf variants of those,
> there are iterators for that).
>
> KF is IEEE QP float.  TF is whatever long double maps to, IEEE QP or
> double-double.
>
> > And if yes,
> > the operand constraints would still be f,d and d for TF->SF or what?
>
> SF is "f".  KF does not fit in "d".
>
> You won't need constraints anyway.  There already is add3_odd and
> you can just use that, in a new defione_expand you make.  For example,
> for DP you need two insns: xsaddqpo followed by xscvqpdp.  The second
> of those is the existing insn pattern truncdf2_hw, so you just get
> something like
>
> (define_expand "adddfkf2"
>   [(set (match_operand:DF 0 "gpc_reg_operand")
> (unspec:DF [(match_operand:IEEE128 1 "gpc_reg_operand")
> (match_operand:IEEE128 2 "gpc_reg_operand")]
>UNSPEC_DUNNO_MENTION_DF_SOMEHOW))]
>   "TARGET_FLOAT128_HW && FLOAT128_IEEE_P (mode)"
> {
>   rtx tmp = gen_reg_rtx (mode);
>   emit_insn (gen_add3_odd (tmp, operands[1], operands[2]);
>   emit_insn (truncdf2_hw (operands[0], tmp));
>   DONE;
> })
>
> (not tested at all, be careful :-) )
>
> > Also, just as we generated fadds/xsaddsp instructions for fadd, would
> > I be generating the same ones for faddl and fadd/xsadddp for daddl
> > (long double to double) or something different? all for ISA 2.07. (for
> > ISA 3.0, I might use IEEE128/FLOAT128 round-to-odd instructions like
> > add_odd followed by conversion to narrower?)
>
> For ISA 2.07 (Power 8) you don't have IEEE128 at all, not in hardware
> that is.  I don't know if we'll want fadd support in the emulation
> libraries ever; don't worry about it for now, anyway.
>
> "long double is double" you should probably handle in generic code.
> "long double is double-double", well, fadd cannot really be done better
> than an add followed by a conversion in that case?  Which boils down
> to truncating the inputs to double, and then doing whatever you would
> do for IEEE DP float.
>
>
> Segher

Re: Rust front-end

[Mateus Carmo Martins de Freitas Barbosa]

> One approach would be something like how the GCC Go frontend works,
> which uses a library shared with the other Go compiler implementation
> to parse the code, and turn it into GCC's IR, which then goes through
GCC's optimizer and backend.

I'm not familiar with rustc's internal working. Its code seems to be
pretty modular but I'm not sure whether those modules are available for external
use (i.e. have a stable API).
If they are, I assume that with this approach it would be necessary to transform
rust's MIR into one of GCC's IRs (e.g. GIMPLE or GENERIC), and there doesn't
seem to be any MIR specification yet
(), so it's likely
not stable enough.

> Another approach would be to build a gcc-based backend to the existing
> rust compiler, as an alternative to its LLVM-based backend, rather than
> a rust frontend to gcc.  libgccjit (despite its name) has the ability
> to generate ahead-of-time code (e.g. .o files), and has rust bindings,
> and thus could be embedded inside rustc - in theory, at least.

This approach seems cleaner to me. libgccjit seems to abstract away IR details,
and it's really convenient that Rust bindings already exist.

I'll take this discussion to the rustc project. Thanks to all.

On Tue, Aug 27, 2019 at 11:58 AM David Malcolm  wrote:
>
> On Fri, 2019-08-23 at 11:10 -0300, Mateus Carmo Martins de Freitas
> Barbosa wrote:
> > I'm interested in working on the Rust front-end for GCC.
> >
> > So far I've cloned the repository  > git>
> > and tried to compile it as described in  > tFrontEnd>.
> > I've compiled it outside of the gcc directory tree with
> >
> > $ ../gccrs/configure --prefix=/opt/gccrs --enable-languages=rust
> > --disable-multilib --disable-bootstrap
> > $ make
> >
> >
> > But this produces some linking errors for functions that were called
> > but never defined:
> >
> >
> > /usr/bin/ld: rust/rust-lang.o: in function
> > `rust_langhook_handle_option(unsigned long, char const*, long, int,
> > unsigned int, cl_option_handlers const*)':
> > /home/baal/gccrs-build/gcc/../../gccrs/gcc/rust/rust-lang.c:185:
> > undefined reference to `rust_add_search_path(char const*)'
> > /usr/bin/ld: /home/baal/gccrs-build/gcc/../../gccrs/gcc/rust/rust-
> > lang.c:213:
> > undefined reference to `rust_add_search_path(char const*)'
> > /usr/bin/ld: /home/baal/gccrs-build/gcc/../../gccrs/gcc/rust/rust-
> > lang.c:217:
> > undefined reference to `rust_add_search_path(char const*)'
> > /usr/bin/ld: rust/rust-lang.o: in function
> > `rust_langhook_post_options':
> > /home/baal/gccrs-build/gcc/../../gccrs/gcc/rust/rust-lang.c:245:
> > undefined reference to `rust_add_search_path(char const*)'
> > /usr/bin/ld: rust/rust-lang.o: in function
> > `rust_langhook_parse_file()':
> > /home/baal/gccrs-build/gcc/../../gccrs/gcc/rust/rust-lang.c:282:
> > undefined reference to `rust_parse_input_files(char const**, unsigned
> > int, bool)'
> > /usr/bin/ld: rust/rust-lang.o:/home/baal/gccrs-build/gcc/./gtype-
> > rust.h:24:
> > undefined reference to `rust_non_zero_struct'
> > collect2: error: ld returned 1 exit status
> > make[2]: *** [../../gccrs/gcc/rust/Make-lang.in:61: rust1] Error 1
> > make[2]: Leaving directory '/home/baal/gccrs-build/gcc'
> > make[1]: *** [Makefile:4319: all-gcc] Error 2
> >
> >
> > It's doesn't really help that the latest commit message
> > (3b1e76d808b9725e6ef439ae534011370e65fb85) says simply "x" and the
> > previous one, only "more". Anyhow, I'm left with those questions:
> >
> > - Considering I'm new to gcc development, what should I read before
> > getting into this?
> > - Is there any developer in particular I should talk to?
>
> As far as I can tell, this is a side-project by one gcc developer
> ("redbrain" aka Philip Herron), who appears to only work on it
> intermittently.  It may not be the best start for someone new to gcc
> development.
>
> I've CCed him on this email (hi Philip!) as I suspect he hasn't seen
> this thread (or might be on vacation).
>
> > - Is there anything else I need to know before getting started?
>
> FWIW, I'm not convinced that a rust frontend to gcc is the best
> approach - Rust has some complicated semantic-checking rules that must
> be implemented by a compiler (the "borrow checker").  Hopefully that
> code is available via a library.
>
> One approach would be something like how the GCC Go frontend works,
> which uses a library shared with the other Go compiler implementation
> to parse the code, and turn it into GCC's IR, which then goes through
> GCC's optimizer and backend.
>
> Another approach would be to build a gcc-based backend to the existing
> rust compiler, as an alternative to its LLVM-based backend, rather than
> a rust frontend to gcc.  libgccjit (despite its name) has the ability
> to generate ahead-of-time code (e.g. .o files), and has rust bindings,
> and thus could be embedded inside rustc - in theory, at lea

Re: Expansion of narrowing math built-ins into power instructions

[Segher Boessenkool]

> > > > [ Please don't top-post ]

(I delete everything under your signature, without looking, assuming you
just forgot to).

On Sat, Aug 31, 2019 at 12:48:42AM +0530, Tejas Joshi wrote:
> > For ISA 2.07 (Power 8) you don't have IEEE128 at all, not in hardware
> > that is.  I don't know if we'll want fadd support in the emulation
> > libraries ever; don't worry about it for now, anyway.
> 
> What instructions would need to be expanded for FADDL (long double to
> float) and DADDL (long double to double) on power8 (ISA 2.07) and
> power9 (ISA 3.0) respectively, along with VSX? (Just as we expanded
> FADD to fadds and xsaddsp for vsx).

If long double is double, faddl is the same as fadd, and daddl is just
normal addition.

If long double is double-double, faddl can be done as fadd on the first
double precision component of both args, and daddl is just normal addition
of those.

If long double is IEEE QP, then it is more interesting :-)

daddl is
  xsaddqpo # add qp, with round to odd
  xscvqpdp # convert qp to dp

faddl is
  xsaddqpo  # add qp, with round to odd
  xscvqpdpo # convert qp to dp, with round to odd
  xsrsp # convert dp to sp
(single precision numbers are stored in double precision format, but
 this is rounded as single precision)

fadds is
  fadds ;  :-)
or
  xsaddsp

Both faddl and daddl are the sequences for Power9.  There are no instructions
for QP format on Power8; see libgcc/config/rs6000/t-float128 for how support
for the emulation QP math is built, if you are interested.


Segher

gcc-8-20190830 is now available

[gccadmin]

Snapshot gcc-8-20190830 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/8-20190830/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8-branch 
revision 275227

You'll find:

 gcc-8-20190830.tar.xzComplete GCC

  SHA256=4b05c96968a679b63db6590fe2d047f9ef5df2676a06093df7fb00045289e427
  SHA1=2f7806035f30735f1ecef30d6c1b935bc079a8e9

Diffs from 8-20190823 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-8
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.