similar to: [LLVMdev] EVT::isRound on non-8-bit byte targets

Hi Sam, On 09/07/13 17:01, Sam Cristall wrote: > I'm new to LLVM dev, but I have been working with a target with a > minimum addressable byte of 16-bits. I found that in > DAGCombiner::visitAND, EVT::isRound could create i8 loads on my 16-bit > target which are ultimately invalid. EVT::isRound appears to use a > hard-coded 8, rather than pulling the targets BitsPerByte field.

(Not sure if this exactly maps to “truncating store”, but I think it at least touches some of the subjects discussed in this thread) Our out-of-tree-target need several patches to get things working correctly for us. We have introduced i24 and i40 types in ValueTypes/MachineValueTypes (in addition to the normal pow-of-2 types). And we have vectors of those (v2i40, v4i40). And the byte size in our

On 9/25/2017 9:14 AM, Björn Pettersson A wrote: > > (Not sure if this exactly maps to “truncating store”, but I think it > at least touches some of the subjects discussed in this thread) > > Our out-of-tree-target need several patches to get things working > correctly for us. > > We have introduced i24 and i40 types in ValueTypes/MachineValueTypes > (in addition to

Hi All, I found a regression which triggers the asserts: "Binary operator types must match!" and "Op types should be identical!". It's happening with a piece of vector code, and the asserts happen because a logic operation is attempted between a vector and a scalar (which is not present in the original code, but created by InstCombine). It's caused by revision

I'm working with an experimental backend for an MCU with heavy multithreading capabilities but lacks proper acquire/release semantics. This is okay, as the programmer can customize __cxa_guard_acquire and __cxa_guard_release to lower/raise appropriate semaphores. The issue I'm having is that I can't seem to figure out when to lower atomic load into an acquire/load pair early

On Wed, Jul 29, 2009 at 3:45 AM, Nicolas Capens<nicolas at capens.net> wrote: > So could anyone who knows the ins and outs of this code have a look at how > to make it handle vectors correctly? Or if that’s not an option right now, > please revert the broken optimizations. Note that there might be more things > affected than visitAnd, visitOr and vistXor, I’ve only been able to

/Volumes/mrs5/net/llvm/llvm/lib/Transforms/Scalar/ InstructionCombining.cpp: In member function ‘llvm::Instruction*<unnamed>::InstCombiner::visitAnd (llvm::BinaryOperator&)’: /Volumes/mrs5/net/llvm/llvm/lib/Transforms/Scalar/ InstructionCombining.cpp:3597: warning: ‘RHSCC’ may be used uninitialized in this function /Volumes/mrs5/net/llvm/llvm/lib/Transforms/Scalar/

They are starting to look complicated. The patch linked is interesting, perhaps v1 vectors are special cased. It shouldn't be too onerous to work out what one or two in tree back ends do by experimentation. Thanks again, it's great to have context beyond the source. On Fri, Sep 15, 2017 at 9:41 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 9/15/2017 12:10 PM, Jon

So what is the correct behavior of the store <2 x i2>. Storing two bytes with a zext:ed i2 in each, or a bit packed vector? I can't remember any documentation mentioning that vectors are bit packed. But if LLVM is supposed to bit pack vectors, should we do it for any element size, or only when element size is less than the byte size, or only for i1 vectors? Maybe bit packing should be

Thanks, Chris, for supporting the idea to have non-8-bits byte in LLVM. I want to clarify the scope and then analyze the options we have. The scope: 1. BitsPerByte or similar variable should be introduced to data layout; include/CodeGen/ValueTypes.h and some other generic headers also need to be updated and probably become dependent on the data layout. 2. Magic number 8 should be replaced with

There seems to be quite a few places where the EVT type is used, but the code asserts if the variable/parameter is assigned something else than an MVT. Are there any general objections to replace EVT with MVT in these cases? For example, a quick look at TargetLowering.h give me this list of (member) functions, taking an EVT parameter, that asserts if the argument is not an MVT: getRegClassFor,

On Dec 3, 2012, at 1:14 PM, Patrik Hägglund H <patrik.h.hagglund at ericsson.com> wrote: > There seems to be quite a few places where the EVT type is used, but the code asserts if the variable/parameter is assigned something else than an MVT. Are there any general objections to replace EVT with MVT in these cases? > > For example, a quick look at TargetLowering.h give me this

On Dec 5, 2012, at 4:51 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > On 3 Dec 2012, at 23:45, Chris Lattner wrote: > >> Please do. MVT is cheaper than EVT and conceptually cleaner when dealing with physical machine types. EVT should only be used in parts of the code generator that are "pre-legalization" because they can represent arbitrary IR types.

On 3 Dec 2012, at 23:45, Chris Lattner wrote: > Please do. MVT is cheaper than EVT and conceptually cleaner when dealing with physical machine types. EVT should only be used in parts of the code generator that are "pre-legalization" because they can represent arbitrary IR types. Anything that takes a legal machine type should take an MVT. A side issue of this is that it is

Hi all, As Samba users, we often interact with Windows environments. I've developped a PERL script that may be useful to you : it is an .evt (Windows event "log" files) viewer. It is inspired from fccu-evtreader (www.d-fence.be) and displays the contents of an event file. It is available on my website (http://contribs.martymac.com/evtViewer/evtViewer-0.2.tgz) and released under the

Hi, I was doing a Kolmogrov test on x, y shown below. They are both 151 long. According to the help file, exact p-value is not available so I set "exact = FALSE", but still got the warning. There are no duplicated values in either X or Y. Thank you for your tips. BTW, is there functions in R about Extreme value theory? ******************************************** > ks.test(x, y,

Hi Patrik, Thanks for this note. It's encouraging to read there has been some provision made for non-8-bit bytes. I'm not a compiler/backend expert, (although maybe I'll need to be soon!), so I won't look at the patches right now, however may at some stage in the future myself or colleague may request these patches from yourself. Yes, our 24-bit architectures have non-power-of-2

Here is a series of patches replacing EVT with MVT at a number of places in TargetLowering. The last two patches are related cleanups in SelectionDAGBuilder. /Patrik Hägglund > git log --stat --reverse origin/master.. commit 8dabe3eb005360347eabb86a2e88c3b6e9098ed5 Author: Patrik Hägglund <patrik.h.hagglund at ericsson.com> Date: Tue Dec 4 10:37:37 2012 +0100 Change

On 24/10/2019 14:21, JF Bastien via llvm-dev wrote: > I’d like to understand what programming model you see programmers using. > You don’t need 257 bits per byte if you only offer 257 bit integers. > Rather, bytes aren’t really a thing at that point. LLVM kinda handles iN > already, and your backend would legalize everything to exactly this type > and nothing else, right? Would

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head><meta http-equiv="content-type" content="text/html; charset=utf-8" /><style type="text/css"><!-- #msg dl { border: 1px #006 solid; background: #369; padding: