search for: regtypes

Hi, I'm porting some existing code of mine to CVS HEAD, and don't understand something about new RegisterClass TableGen definition: class RegisterClass<string namespace, list<ValueType> regTypes,........ { ..... string Namespace = namespace; What is this "namespace" thing? It looks like it should contain the name of backend, right? // RegType - Specify the ValueType of the registers in this register // class. Note that all registers in a register class mu...

On Sat, 13 May 2006, Vladimir Prus wrote: > I'm porting some existing code of mine to CVS HEAD, and don't understand > something about new RegisterClass TableGen definition: > > class RegisterClass<string namespace, list<ValueType> regTypes,........ > { > ..... > string Namespace = namespace; > > What is this "namespace" thing? It looks like it should contain the name of > backend, right? Right. This is "X86" "Alpha" "PPC" etc, which is used to prefix register...

Hello r-help, I am using the excellent np package to conduct a nonparametric kernel regression and am having some trouble plotting the results. I have 2 covariates, x1 and x2, and a continuous outcome variable y. I am conducting a nonparametric regression of y on x1 and x2. The one somewhat unusual feature of these data is that, to be included in the dataset, x1 must be at least as large as x2.

...ps it > doesn't matter how it works under the hood to the average backend > writer. I agree with the complexity, but I would hope that more documentation, examples and explanations would clarify it. > What if RegisterClass contained a `list<RCInfo>`. Each RCInfo contains > RegTypes, RegSize, SpillSize, and SpillAlignment as well as a > Predicate the determines whether this individual RCInfo is the one > that should apply. To my taste this seems easier to understand than > the {Int,ValueType,ValueTypeList}Select mechanism. The "select" mechanism was intende...

On 08/31/2015 03:59 PM, Matthias Braun wrote: > Looks to me like the alignment is specified in tablegen. From Target.td: > > class RegisterClass<string namespace, list<ValueType> regTypes, int alignment, > dag regList, RegAltNameIndex idx = NoRegAltName> > > X86RegisterInfo.td: > > def VR256 : RegisterClass<"X86", [v32i8, v16i16, v8i32, v4i64, v8f32, v4f64], > 256, (sequence "YMM%u", 0, 15)&g...

Patch for review. On Mon, Aug 21, 2017 at 11:45 PM Puyan Lotfi <puyan.lotfi.llvm at gmail.com> wrote: > Ping. > > Still working on preparing code for review. Will have a patch for review > ready in the coming days. > > PL > > On Tue, Aug 15, 2017 at 12:06 PM Puyan Lotfi <puyan.lotfi.llvm at gmail.com> > wrote: > >> Hi, >> >> >>

> > > > > def SDTX86CmpPTest : SDTypeProfile<1, 2, [SDTCisVT<0, i32>, > SDTCisVec<1>, > SDTCisSameAs<2, 1>]>; > > This is confusing to me. This tells me that there is 1 result but and 2 > operands. But then it says that operands 2 and 1 are of the same type,

...: HwModeSelect<Ms> { // Select a list of value types. list<list<ValueType>> Values = Ls; } 3. The class RegisterClass would get new members to hold the configurable size/alignment information. If defined, they would take precedence over the existing members RegTypes/Size/Alignment. class RegisterClass { ... ValueTypeListSelect VarRegTypes; // The names of these members IntSelect VarRegSize; // could likely be improved... IntSelect VarSpillSize; // IntSelect VarSpillAlignment // } To fully implement...

Looking around today, it appears that TargetRegisterClass and MCRegisterClass only includes a single alignment. This is documented as being the minimum legal alignment, but it appears to often be greater than this in practice. For instance, on x86 the alignment of %ymm0 is listed as 32, not 1. Does anyone know why this is? Additionally, where are these alignments actually defined? I

The blow snippet in target.td shows the regList in RegisterClass is typed as dag. Why not make it a simple list, such as list<Register>? class RegisterClass<string namespace, list<ValueType> regTypes, int alignment, dag regList> Thanks, -Thomson -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140119/86188ec8/attachment.html>

Dear all, I am using np package in order to estimate a model with Klein and Spady estimator. To estimate the model I use KS <- npindexbw (xdat=X, ydat=Y, bandwidth.compute=TRUE, method="kleinspady", optim.maxit=10^3, ckertype="epanechnikov", ckerorder=2) and to estimate beta hats standard errors I use KSi <- npindex(KS, gradients=T, boot.num=300) vcov(KSi) This is

Hello all, I have two Tablegen questions in the context of an unconventional architecture. The pertinent details: the architecture has multiple register files that are selected via a bit in the instruction. One of the register files is a traditional one. The other is unconventional in that all source and dest registers are both read from and written to by the instructions. So add special0,

...output register, it's just an implicit flag register. It still has a DAG output. I'm not sure if the allocatable bit matters at this point for selection purposes, but it does later. Not adding a type to the register class can also be problematic (e.g. a flag register should have i1 added to regTypes for its class). -Matt > Does LLVM make an assumption that there is an implicit register output if there are no outputs given to the pattern? I'm also curious about how did LLVM know that an output of this instruction was setting a flag in a special purpose register rather than a GPR? When...

> On Behalf Of Nicholas Chapman > > On 04/12/2012 06:29, Michael Spencer wrote: > > On Mon, Dec 3, 2012 at 8:08 PM, Gordon Keiser <gkeiser at arxan.com> > wrote: > >> As an update to this: > >> http://connect.microsoft.com/VisualStudio/feedback/details/769222/cl- > >> exe-ice-when-building-llvm-trunk-at-o2 > >> > >> Microsoft

On 04/12/2012 06:29, Michael Spencer wrote: > On Mon, Dec 3, 2012 at 8:08 PM, Gordon Keiser <gkeiser at arxan.com> wrote: >> As an update to this: >> http://connect.microsoft.com/VisualStudio/feedback/details/769222/cl-exe-ice-when-building-llvm-trunk-at-o2 >> >> Microsoft has reproduced the ICE, given a workaround, and is planning a fix for a future MSVC release.

A very miscellaneous set of cleanups to how we handle the Windows registry in virt-v2v, firstboot, and inspection code. This should all be straightforward non-controversial refactoring. Some highlights: - Add a new mllib Registry module containing various utility functions that are currently scattered all around. - Only compute the software/system hive paths once during inspection, and

OCaml 4.02 introduced the 'bytes' type, a mutable string intended to replace the existing 'string' type for those cases where the byte array can be mutated. In future the 'string' type will become immutable. This is not the default now, but it can be forced using the '-safe-string' compile option. I tested this on Fedora 24 (OCaml 4.02) & RHEL 7 (OCaml 4.01).

This used to be a single patch, but I split it into two with the addition of struct Scatterlist. Again a bit new with Rust submissions. I was told by Gary Guo to rebase on top of rust-next, but it seems *very* behind? The first patch does not build on its own due to a dead_code warning. It is hard to not have dead code when one is adding infrastructure to be used by others at a later