search for: ingrain

...Eli Friedman via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I don’t see any particular reason to guarantee that a volatile memcpy will access each byte exactly once. How is that useful? I agree it's probably not that useful, but I think the non-duplicating property of volatile is ingrained strongly enough that viewing a memcpy as a single load and store to each unit (in an unspecified order) should be legitimate; so I think this actually is a bug. As the documentation says though, it's unwise to depend on the behaviour of a volatile memcpy. Cheers. Tim.

Greetings all! I've got some really silly questions. I'm a technical guy, and I understand how the astrisk server works and how VOIP works, etc... The problem I have is that at my small company we have a phone system with analog lines and everyone here is comfortable with the concept of using them. I've never seen IP phones in action so I don't know how they work from a users

...n I'm compiling for -mips32 -nomips16 The ARM tGPR register class is the same. It has no business showing up in non-Thumb code, but it is completely harmless when it does. My best advice to you is don't try to swim upstream. The Liskov substitution principle for register classes is deeply ingrained in the LLVM register allocators. /jakob

On 05/14/2012 02:17 PM, Jakob Stoklund Olesen wrote: > On May 14, 2012, at 1:02 PM, reed kotler wrote: > >> Does anyone understand the purpose of : >> >> TargetRegisterInfo::getMinimalPhysRegClass ??? > Barely. > >> Why is there the presumption to use the minimal subclass? > The function can be traced back to a time when men were men and registers belonged to

Is this the prefered method to implement RedCloth in your views. I''m trying to display user input that will sometimes have code references in it. This strips out all tags. I would like for the tags to be displayed but not read as html. Thanks in advance! <%= RedCloth.new(strip_tags(comment.comment),[:filter_html]).to_html %> charlie bowman recentrambles.com -- Posted via

...piling for -mips32 -nomips16 > The ARM tGPR register class is the same. It has no business showing up in non-Thumb code, but it is completely harmless when it does. > > My best advice to you is don't try to swim upstream. The Liskov substitution principle for register classes is deeply ingrained in the LLVM register allocators. > > /jakob > I guess I can just fix the problem with: if ((RC == &Mips::CPU16RegsRegClass) && !TM.getSubtargetImpl()->inMips16Mode()) RC = &Mips::CPURegsRegClass;

...I would keep it. Well, the issue for me is that "a.out" in LLVM land can be a shell script and even if its a native executable, it probably isn't in the ancient a.out format. perhaps we need "some" default, but not "a.out"? or, are you saying this default is so ingrained into developer's minds that it just needs to be supported regardless of the fact that it no longer makes sense? > > -Brian > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http...

...ister allocation, and represent all your "physical" registers > are virtual registers. This gives you an unlimited number. > Yes it would be ideal to use all virtual registers, but a glance at the code seemed to indicate the the use of physical registers, spilling, etc. was pretty ingrained in all the register allocation algorithms, so it seemed like it would be difficult to extract. I also still need to minimize the number of registers and minimize copies as if it were generating code for more restrictive hardware. Ideally I'd like something like the linear register allocator...

...ips32 -nomips16 >> The ARM tGPR register class is the same. It has no business showing up in non-Thumb code, but it is completely harmless when it does. >> >> My best advice to you is don't try to swim upstream. The Liskov substitution principle for register classes is deeply ingrained in the LLVM register allocators. >> >> /jakob >> > I guess I can just fix the problem with: > > if ((RC == &Mips::CPU16RegsRegClass) && > !TM.getSubtargetImpl()->inMips16Mode()) > RC = &Mips::CPURegsRegClass; Can I ask what concrete p...

...tors and register allocations. It's particularly troublesome because the SSI sigma instruction defines multiple variables, whereas the SSA form instructions can only define a single value (in fact, LLVM's Instruction class is an indirect subclass of the Value class), and this assumption is ingrained in LLVM. It doesn't sound like you're prepared to update the entire LLVM codebase to be built on SSI -- you want to make SSI an offshoot of the SSA form, and that's hard to accomodate as that means every pass will have to know about and support SSI form, not just the ones you write....

hello Sean, On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote: > I'd really prefer this patch (series or single) is not accepted. This > will cause problems for everyone cherry-picking patches to a > downstream kernel (LTS or distro tree). I usually wouldn't expect > sympathy here, but the questionable benefit does not outweigh the cost > IM[biased]O. I agree that

hello Sean, On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote: > I'd really prefer this patch (series or single) is not accepted. This > will cause problems for everyone cherry-picking patches to a > downstream kernel (LTS or distro tree). I usually wouldn't expect > sympathy here, but the questionable benefit does not outweigh the cost > IM[biased]O. I agree that

...houldn't be an issue then any more. You've rightly identified the conjecture in your statement. I've been on both sides of the argument, having written/maintained drm code upstream and cherry-picked changes to a downstream kernel. Perhaps it's because drm's definition of dev is ingrained in my muscle memory, or maybe it's because I don't do a lot of upstream development these days, but I just have a hard time seeing the benefit here. I appreciate your engagement on the topic, thank you! Sean > > Thanks for your input, best regards > Uwe > > -- > Pengu...

...houldn't be an issue then any more. You've rightly identified the conjecture in your statement. I've been on both sides of the argument, having written/maintained drm code upstream and cherry-picked changes to a downstream kernel. Perhaps it's because drm's definition of dev is ingrained in my muscle memory, or maybe it's because I don't do a lot of upstream development these days, but I just have a hard time seeing the benefit here. I appreciate your engagement on the topic, thank you! Sean > > Thanks for your input, best regards > Uwe > > -- > Pengu...

Dear LLVM Community, I'm a Computer Science master student at UFMG, Brasil. I'm interested in taking part on Google Summer of Codes 2009. My idea is not on the LLVM list, but I have written a project description to make my intentions clear. My project is attached as a pdf file. Regards, -- Andre Tavares Master Student in Computer Science - UFMG - Brasil http://dcc.ufmg.br/~andrelct

...-dev at lists.llvm.org> wrote: >>> I don’t see any particular reason to guarantee that a volatile memcpy will access each byte exactly once. How is that useful? >> >> I agree it's probably not that useful, but I think the non-duplicating >> property of volatile is ingrained strongly enough that viewing a >> memcpy as a single load and store to each unit (in an unspecified >> order) should be legitimate; so I think this actually is a bug. >> >> As the documentation says though, it's unwise to depend on the >> behaviour of a volatile...

...> >> You've rightly identified the conjecture in your statement. I've been >> on both sides of the argument, having written/maintained drm code >> upstream and cherry-picked changes to a downstream kernel. Perhaps >> it's because drm's definition of dev is ingrained in my muscle memory, >> or maybe it's because I don't do a lot of upstream development these >> days, but I just have a hard time seeing the benefit here. > > I can only second what Sean writes. I've done quite a bit of backporting > of DRM code. It's hard a...

...> >> You've rightly identified the conjecture in your statement. I've been >> on both sides of the argument, having written/maintained drm code >> upstream and cherry-picked changes to a downstream kernel. Perhaps >> it's because drm's definition of dev is ingrained in my muscle memory, >> or maybe it's because I don't do a lot of upstream development these >> days, but I just have a hard time seeing the benefit here. > > I can only second what Sean writes. I've done quite a bit of backporting > of DRM code. It's hard a...

...t; allocations.  It's particularly troublesome because the SSI sigma > instruction defines multiple variables, whereas the SSA form instructions > can only define a single value (in fact, LLVM's Instruction class is an > indirect subclass of the Value class), and this assumption is ingrained in > LLVM. While it is not described in the litterature, I don't think you need to introduce a new function: x0 = ... x1, x2 = \sigma (x0) | +----+------+ | | v v ... = x1 ... = x2 Can be transformed to: x0 = ......

...he tables in use, but `ip route show table all` will give you all the routing tables in use on your system (even in a default install it's a lot more than the route command shows) and ip rule gives you the rules in use, if any. On a similar note bridge-utils is also deprecated, though brctl is ingrained into many minds! https://fedoramagazine.org/build-network-bridge-fedora/