search for: softening

Any thoughts? I have half a mind to turn it on by default, but I guess it's better not to. -- Martin -------------- next part -------------- An embedded message was scrubbed... From: Marco d'Itri <md@Linux.IT> Subject: Re: rsync and debian mirrors Date: Fri, 19 Apr 2002 14:58:58 +0200 Size: 4416 Url: http://lists.samba.org/archive/rsync/attachments/20020419/b22ddd1a/attachment.eml

On Jul 14, 2014, at 7:23 AM, Tom Stellard <tom at stellard.net> wrote: > On Mon, Jul 14, 2014 at 01:08:54PM +0100, Tim Northover wrote: >> Hi all, >> >> What do people think of doing away with the @llvm.convert.to.fp16 and >> @llvm.convert.from.fp16 intrinsics, in favour of using "half" and >> fpext/fptrunc? [1] >> > > I am in favor

Hi Xerxes, > 4. softfloat related errors > http://labb.zafena.se/shark-testing/llvmARMCodeGenFailures200904/softenfloat_Do_not_know_how_to_soften_the_result_of_this_operator/ > example: > > root at overo:/home/xerxes/llvm-test/fail/CodeGen/softenfloat# llvm-as < 2007-11-19-VectorSplitting.ll | llc > SoftenFloatResult #0: 0x614e00: f32 = undef > llc:

Duncan Sands wrote: > Hi Sanjiv, I think a lot of the softening code assumes you are dealing > with float (32 bits). So it's not just a matter of changing the libcall > return type. > Yes, we are dealing with 32-bits only. But why the cmp libcalls have to return a 32-bit value. e.g. Our libcall for comparing two floats is char _eq_f32 (float a...

Sanjiv Gupta wrote: > Sanjiv Gupta wrote: > >> Duncan Sands wrote: >> >> >>> Hi Sanjiv, I think a lot of the softening code assumes you are dealing >>> with float (32 bits). So it's not just a matter of changing the libcall >>> return type. >>> >>> >>> >> Yes, we are dealing with 32-bits only. But why the cmp libcalls have to >> return a 32-...

...I found that long double complex (with two f128 values) also have calling convention compatibility problem with gcc and can be fixed similarly. My current patch does change quite a few places in type legalizing pass and some other optimizations related to f128 or i128 values. A few changes in the softening of floating point types to keep some f128 typed IR and convert some f128 opcode to library function calls. Has anyone tried this approach or have other solution? Thanks -- Chih-Hung -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermai...

On 01/28/2013 06:51 PM, Hal Finkel wrote: > Is this sufficient to implement #pragma ivdep in clang? I'm not completely sure of this: "Note: The proven dependencies that prevent vectorization are not ignored, only assumed dependencies are ignored."

...because > we lose out on intermediate rounding. > > > > It seems like what we should instead do is insert fp16_to_fp and > fp_to_fp16 in the libcall and arithmetic op handling. And use i16 to > connect the legalized pieces together. Similar to how we use integer types > when softening operations. I'm not sure if there would still be rounding > issues with this, but it seems closer to matching the IR. > > > > Unfortunately, I think this would have the side effect of changing half > arguments and return types to i16 instead of float, which would be an ABI &gt...

Hello Evan and Robert I have been investigating the unexpected test failures from the ARM nightly builders in order to get a better picture why the ARM backend don't pass the whole testsuite: I have run the failing tests manually on my arm board and can now categorize most of the thirteen unexpected CodeGen failures in four categories: 1. llvm don't lower MVT::i64 properly on arm

Hi, What is the best way to deal with I/O load when running several VMs on a physical machine with local or remote storage? What I'm primarily worried about is the case when several VMs cause disk I/O at the same time. One example would be the "updatedb" cronjob of the mlocate package. If you have say 5 VMs running on a physical System with a local software raid-1 as storage and

Duncan Sands skrev: > Hi Xerxes, > > >> 4. softfloat related errors >> http://labb.zafena.se/shark-testing/llvmARMCodeGenFailures200904/softenfloat_Do_not_know_how_to_soften_the_result_of_this_operator/ >> example: >> >> root at overo:/home/xerxes/llvm-test/fail/CodeGen/softenfloat# llvm-as < 2007-11-19-VectorSplitting.ll | llc >>

While generating a libcall from floating point comparison, it always assumes that the return type of those libcalls is i32. Why not allow Targets to provide the correct return type? EVT RetVT = MVT::i32; // <-- here SDValue Ops[2] = { LHSInt, RHSInt }; NewLHS = MakeLibCall(LC1, RetVT, Ops, 2, false/*sign irrelevant*/, dl); NewRHS = DAG.getConstant(0, RetVT); CCCode =

Hi Sanjiv, I think a lot of the softening code assumes you are dealing with float (32 bits). So it's not just a matter of changing the libcall return type. > While generating a libcall from floating point comparison, it always > assumes that the return type of those libcalls is i32. > Why not allow Targets to provide the co...

Sanjiv Gupta wrote: > Duncan Sands wrote: > >> Hi Sanjiv, I think a lot of the softening code assumes you are dealing >> with float (32 bits). So it's not just a matter of changing the libcall >> return type. >> >> > Yes, we are dealing with 32-bits only. But why the cmp libcalls have to > return a 32-bit value. > e.g. Our libcall for compari...

On Mon, Oct 5, 2009 at 11:11 AM, Sanjiv Gupta <sanjiv.gupta at microchip.com> wrote: > Sanjiv Gupta wrote: >> Sanjiv Gupta wrote: >> >>> Duncan Sands wrote: >>> >>> >>>> Hi Sanjiv, I think a lot of the softening code assumes you are dealing >>>> with float (32 bits).  So it's not just a matter of changing the libcall >>>> return type. >>>> >>>> >>>> >>> Yes, we are dealing with 32-bits only. But why the cmp libcalls have to >>&g...

...t 5, 2009 at 11:11 AM, Sanjiv Gupta > <sanjiv.gupta at microchip.com> wrote: > > Sanjiv Gupta wrote: > >> Sanjiv Gupta wrote: > >> > >>> Duncan Sands wrote: > >>> > >>> > >>>> Hi Sanjiv, I think a lot of the softening code assumes you are > dealing > >>>> with float (32 bits). So it's not just a matter of changing the > libcall > >>>> return type. > >>>> > >>>> > >>>> > >>> Yes, we are dealing with 32-bits onl...

On 01/28/2013 07:36 PM, Pekka Jääskeläinen wrote: > If there's a "yes" from the analyzer it still prevents the vectorization. > So, sort of a softened programmer-friendlier version of the semantics. That said, I cannot think of a case where it would *harm* if the dependency analyzer, if it can actually prove a dependency, serializes the code. Thus, the same metadata can be

This is probably the most eternal question concerning rsync, but I'm really in doubt since I can't find the appropriate answer or solution anywhere for many months. I'm using rsync for simple daily back up data from one HD to another. It takes about 10 minutes daily under "nice -n 19". The problem is well-known as I see - several other services such as

----- Original Message ----- > From: "Nadav Rotem" <nrotem at apple.com> > To: "Pekka Jääskeläinen" <pekka.jaaskelainen at tut.fi> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Monday, January 28, 2013 10:45:36 AM > Subject: Re: [LLVMdev] [PATCH] parallel loop awareness to the LoopVectorizer > > Hi Pekka,

Hi! Sorry, I know the rules for comparing objective subjective listening impressions, but I'd like to know whether from the algorithmic or implementer's point of view the following personal impressions can be confirmed: Comparing MP3 with Vorbis at rather high bitrates, I had the impression the Vorbis sounded more crispy, while MP3 sounded somewhat softened. I preferred Vorbis for that