search for: regtyp

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

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

...norm(num_obs,0,1) y <- x1^2 + x2^2 + x1*x2 + e mydata <- data.frame(x1=x1,x2=x2,y=y,e=e) summary(mydata) rm(x1,x2,y,e) # PROBLEM 1: plotting out of sample # example 1: do not restrict data to x1>=x2 # calculate bandwidth using npregbw() bandwidth <- npregbw(formula = y ~ x1 + x2, regtype="ll", bwmethod="cv.aic", data=mydata) summary(bandwidth) # perform nonparametric regression using bandwidth results <- npreg(bws=bandwidth) summary(results) # use plot to plot results plot(results,view="fixed",theta=300) # example 2: restrict data to obs...

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

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

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

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>

...S, gradients=T, boot.num=300) vcov(KSi) This is fine so far, but if I want to estimate the bootstrapped standard errors on estimates by se(KSi) then the result is NA and if I include the argument errors=TRUE instead of the default errors=FALSE as I think I should, I get the error: Error in npreg(regtype = "lc", gradients = TRUE, txdat = rindex, tydat = tydat[indices], : argument is missing, with no default I couldn't find though any argument without a default. So, how can I get the bootstrapped errors? Thank you Dimitris -- View this message in context: http://r.789695.n4....

...s<2> op0Type, RegisterClass Src0RC> { dag insDefault = !if(!eq(op0Type, 0b01), (ins SpecialReg:$dst, Src0RC:$a), (ins Src0RC:$a)); ... } multiclass MultSrc1Spec<bits<5> subOpcode, bits<2> op0t, string opcodeStr, RegisterClass RegType> { def _allspecial: MultSrcOneDestInst<subOpcode, op0t, 0b00, IO_MultSrc<op0t, SpecialReg>.outsDefault, IO_MultSrc<op0t, SpecialReg>.insDefault>; ... } multiclass TwoSrcOneDestSpec<bits<5> subOpcode, str...

...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? Whe...

> 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