search for: soften

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: /usr/src/openembedded/overo/tmp/work/armv...

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 (floa...

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...

...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/piper...

...e used to disable dependency checking altogether (and just blame a sloppy programmer if there actually are dependencies), but it just converts the "unknown alias" to "no alias". If there's a "yes" from the analyzer it still prevents the vectorization. So, sort of a softened programmer-friendlier version of the semantics. The vagueness comes from that it depends on the intelligence of the dependency analysis implementation whether a dependency can be "proven" or not, doesn't it? Thus, #pragma ivdep with a non-existing loop dependence analyzer is equiv...

...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...

...:/home/xerxes/llvm-test/fail/CodeGen/matchmemoryaddress# llvm-as < 2007-04-08-MultipleFrameIndices.ll | llc Could not match memory address. Inline asm failure! .file "<stdin>" Aborted 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: /usr/src/openembedded/overo/tmp/work/armv7a-angstrom-linux-gnueabi...

..." 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 the all run updatedb at the same time that causes all of them to run really slowly because the starve each other fighting over the disk. What is the best way to soften the impact of such a situation? Does it make sense to use a hardware raid instead? How would the raid type affect the performance in this case? Would the fact that the I/O load gets distributed across multiple spindles in, say, a 4 disk hardware raid-5 have a big impact on this? I'm curren...

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 >> SoftenFloatResult #0: 0x614e00: f32 = undef >> llc: /usr/src/openembedded/...

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...

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 comp...

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 >&gt...

...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...

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 used in both cases, if one doesn't care the possible wasted compil...

...as I see - several other services such as httpd or mysql begin responding slowly (up to 10 sec for mysql queries which usually processed in a small fraction of a second). The reason is pretty obvious, but still are there any general recommendations on how to solve or appreciably soften the situation? Best regards, Denis Solovyov

----- 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,

...ve 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 reason. When comparing Opus to Vorbis, I got the impression that Opus has a slight tendency towards MP3, but noe I feel Vorbis' crispyness is maybe a little too much, and I think I'll prefer Opus. Unfortunately my search for a good free player for Android was...