search for: _per_se_

...e. All buffering necessarily has some overhead. > > Buffering has overhead from copying data around. It doesn't matter > whether you do in by using stdio buffering or by building your own > buffers to avoid virtual method overhead. Sure. But that has nothing to do with iostreams _per_se_. > >> How is this different than buffering done by stdio? > > > > It's in front of the virtual calls. So you only invoke virtual > > calls when the > > buffer is full. At that point, you're writing to the file cache at > > best or to > > disk...

...D 4.3. [...] > I'm not suggesting using iostreams. I'm suggesting using FILE*'s > directly. Ah. Basically operator<< for FILE*. I don't see a lot of benefit to redefining operator<< for every type just to avoid ostreams. The problem isn't basic_ostream _per_se_. There are two issues we're worried about: 1. The static constructor contortions in place to handle the extremely unlikely case of a static object constructor writing to one of the standard streams. 2. Slowness of std::cout and friends due to their reliance on FILE * buffering an...

On Fri, 17 Aug 2007, David Greene wrote: >> Posix is pretty available, what system doesn't have them? > > Windows, for one. If POSIX is ok, it's better in my mind to just directly Windows has POSIX calls. > use open, write and friends, which is what I do now. Going the cstdio > route should only be done for portability reasons to support non-POSIX > systems. I

>>> 1. The static constructor contortions in place to handle the >>> extremely >>> unlikely case of a static object constructor writing to one of the >>> standard streams. >> >> I also dislike this strongly, but it isn't really related. > > Isn't this the motivation behind "#include <iostreams> is hereby >

On Fri, 17 Aug 2007, David Greene wrote: > Ah. Basically operator<< for FILE*. I don't see a lot of benefit to > redefining operator<< for every type just to avoid ostreams. The > problem isn't basic_ostream _per_se_. There are two issues we're > worried about: The problem is basic_ostream and the design of the whole iostreams library. Use of virtual base classes makes every virtual method particularly expensive, for example. > 1. The static constructor contortions in place to handle the extreme...

Hi all, Just a quick question about X86 instructions inside LLVM. I found it hard to do one-to-one mapping from the instructions in X86GenInstInfo.inc to the instructions in the intel Manual. For example, what instructions are DIVR_F32m and DIVR_F64m mapped to in the intel manual? It would be great if there is some docs about the X86 instructions. Thanks tons! Bin

On Aug 10, 2007, at 4:15 PM, David Greene wrote: > On Friday 10 August 2007 17:55, David Greene wrote: >> On Friday 10 August 2007 15:12, David Greene wrote: >>> Perhaps an easier way is to just expose the -simple-register- >>> coalescing >>> and -conservative-register-coalescing options to the user, but I >>> don't >>> know how to do

...rily has some overhead. >> >> Buffering has overhead from copying data around. It doesn't matter >> whether you do in by using stdio buffering or by building your own >> buffers to avoid virtual method overhead. > > Sure. But that has nothing to do with iostreams _per_se_. I'm aware of that. > Now, if I were to redesign iostreams, I would try to turn that dynamic > polymorphism into static polymorphism. I think the ability to switch > streambufs at runtime is hardly ever used, so we really don't need virtual > calls. Right. Overall, go ahead...

...must be taken into > account. If "setvl" returns a predicate then that predicate would have > to be combined in some way with the conditional predicate (typically via > an AND operation in an IR that directly supports predicates). Since > LLVM IR doesn't have predicates _per_se_, would it turn into nested > selects or something? Untangling that in instruction selection seems > difficult but perhaps I'm missing something. My idea is for the RISC-V backend to recognize when a setvl intrinsic has been used, and replace the use of its value in AND operations with a...

On Friday 10 August 2007 17:55, David Greene wrote: > On Friday 10 August 2007 15:12, David Greene wrote: > > Perhaps an easier way is to just expose the -simple-register-coalescing > > and -conservative-register-coalescing options to the user, but I don't > > know how to do that on an individual pass bases. opt just jams then all > > in with PassNameParser.

Hi David, >>> The name "getSizeExpressionInBits" makes me think that a Value >>> expression will be returned (something like a ConstantExpr that uses >>> vscale). I would be surprised to get a pair of integers back. Do >>> clients actually need constant integer values or would a ConstantExpr >>> sufffice? We could add a ConstantVScale or

...August 2007 17:01, Chris Lattner wrote: > On Fri, 17 Aug 2007, David Greene wrote: > > Ah. Basically operator<< for FILE*. I don't see a lot of benefit to > > redefining operator<< for every type just to avoid ostreams. The > > problem isn't basic_ostream _per_se_. There are two issues we're > > worried about: > > The problem is basic_ostream and the design of the whole iostreams > library. Use of virtual base classes makes every virtual method > particularly expensive, for example. I don't know about "particularly." T...

...account. If "setvl" returns a predicate then that predicate would have >>> to be combined in some way with the conditional predicate (typically via >>> an AND operation in an IR that directly supports predicates). Since >>> LLVM IR doesn't have predicates _per_se_, would it turn into nested >>> selects or something? Untangling that in instruction selection seems >>> difficult but perhaps I'm missing something. >> >> My idea is for the RISC-V backend to recognize when a setvl intrinsic has >> been used, and replace th...