search for: softened

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, float b); rather than long

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

Hello, I'm new to this mailing list and fixing llvm bugs for Android. Can anyone point me to any previous discussion or work related to the following bug? https://llvm.org/bugs/show_bug.cgi?id=23897 I am testing my patch to llvm to make f128 values stay in SSE registers instead of being split into two i64 values. I have tried to add a register class FR128 to hold f128 values for the x86_64

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

Thanks Eli. I forgot to bring up the strict FP questions which I was working on when I found this. If we're in a strict FP function, do the fp_to_f16/f16_to_fp emitted by promoting load/store/bitcast need to be strict versions of fp_to_f16/f16_to_fp. And if so where do we get the chain, especially for the bitcast case which isn't a chained node. ~Craig On Tue, Dec 10, 2019 at 3:18 PM

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 correct return type? > > EVT RetVT = MVT::i32;

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

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

On Mon, 2009-10-05 at 16:54 -0700, Eli Friedman wrote: > 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

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

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,

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