search for: dylanmckay

Hey all, It seems that the main buildmaster here is working fine http://lab.llvm.org:8011/ However, I have a 'connection refused' error whilst connecting to the staging buildmaster http://lab.llvm.org:8014/ Are you aware of this Victor and Galina? -------------- next part -------------- An HTML attachment was scrubbed... URL:

What do you see as the pros and cons of making it a stable target? Does anyone else have any concerns about doing so? -Chris > On Feb 14, 2020, at 7:59 AM, Nico Weber via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > +better dylanmckay address > > On Fri, Feb 14, 2020 at 10:58 AM Nico Weber <thakis at chromium.org <mailto:thakis at chromium.org>> wrote: > Hi, > > There was a thread a few days ago about the expectations for experimental targets. At the moment, the only experimental target is AVR. It...

...ext entries (or otherwise have an opinion on having them) in debug_aranges? > --paulr > > > > *From:* David Blaikie <dblaikie at gmail.com> > *Sent:* Monday, March 16, 2020 1:20 PM > *To:* Robinson, Paul <paul.robinson at sony.com> > *Cc:* Dylan McKay <me at dylanmckay.io>; llvm-dev at lists.llvm.org > *Subject:* Re: [llvm-dev] DWARF .debug_aranges data objects and address > spaces > > > > On Mon, Mar 16, 2020 at 9:31 AM Robinson, Paul <paul.robinson at sony.com> > wrote: > > With AVR being affected, upstreaming a patch to put...

...on between signed and unsigned number and returns upper 32 bits into result register. I think I also need to write some code probably as you indicated to check signedness of the operands and based on that lower to mulhsu instruction. -Vivek On Mon, Feb 27, 2017 at 11:13 AM, Dylan McKay <me at dylanmckay.io> wrote: > Hey Vivek, > > We don't directly emit the MULSURdRr instruction. On top of this, I don't > believe any of the AVR multiplication instructions have patterns in > TableGen. > > This is because the AVR mul instructions are quite strange. Almost all of >...

...; 0x800061 <v2> 7c: 08 95 ret So, in C++ mode it is not recognized as ISR due to name mangling. Furthermore there are no register push/pos and no reti. Whats wrong? Thanks. Am 11.03.20 um 08:13 schrieb Dylan McKay: > Here you go Wilhelm, > > https://github.com/dylanmckay/clang-avr-libc-interrupt-example > > > > On Thu, Mar 5, 2020 at 4:05 AM Wilhelm Meier <wilhelm.meier at hs-kl.de > <mailto:wilhelm.meier at hs-kl.de>> wrote: > > Am 04.03.20 um 13:28 schrieb Dylan McKay: > > > > >   * *The C/C++ funct...

> -----Original Message----- > From: Hal Finkel [mailto:hfinkel at anl.gov] > Sent: den 13 juli 2017 16:01 > To: Björn Pettersson A <bjorn.a.pettersson at ericsson.com>; David Chisnall > <David.Chisnall at cl.cam.ac.uk>; Dylan McKay <me at dylanmckay.io> > Cc: llvm-dev at lists.llvm.org; Carl Peto <carl.peto at me.com> > Subject: Re: [llvm-dev] RFC: Harvard architectures and default address > spaces > > On 07/13/2017 05:38 AM, Björn Pettersson A via llvm-dev wrote: > > My experience of having the address space for...

...t impose some problems as well. And perhaps it isn't the most general solution. /Björn > -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of David > Chisnall via llvm-dev > Sent: den 12 juli 2017 17:26 > To: Dylan McKay <me at dylanmckay.io> > Cc: llvm-dev <llvm-dev at lists.llvm.org>; Carl Peto <carl.peto at me.com> > Subject: Re: [llvm-dev] RFC: Harvard architectures and default address > spaces > > On 11 Jul 2017, at 23:18, Dylan McKay via llvm-dev <llvm-dev at lists.llvm.org> > wrote: &gt...

Am 04.03.20 um 13:28 schrieb Dylan McKay: > > * *The C/C++ function needs to be declared with either the calling > convention avr-interrupt or avr-non-blocking-interrupt.* Skipping > this step will cause regular ret instructions to be emitted for > return-from-subroutine, instead of the required reti for interrupt > handlers. ISRs also have stricter

Hi, There was a thread a few days ago about the expectations for experimental targets. At the moment, the only experimental target is AVR. It's been in the tree for a long time now, and generally seems well-behaved. Should we just make it a normal target? Nico -------------- next part -------------- An HTML attachment was scrubbed... URL:

...angling. > > > > Furthermore there are no register push/pos and no reti. > > > > Whats wrong? > > > > Thanks. > > > > > > Am 11.03.20 um 08:13 schrieb Dylan McKay: > >> Here you go Wilhelm, > >> > >> https://github.com/dylanmckay/clang-avr-libc-interrupt-example > >> > >> > >> > >> On Thu, Mar 5, 2020 at 4:05 AM Wilhelm Meier <wilhelm.meier at hs-kl.de > >> <mailto:wilhelm.meier at hs-kl.de>> wrote: > >> > >> Am 04.03.20 um 13:28 schrieb Dylan Mc...

...> > > > > Whats wrong? > > > > > > Thanks. > > > > > > > > > Am 11.03.20 um 08:13 schrieb Dylan McKay: > > >> Here you go Wilhelm, > > >> > > >> https://github.com/dylanmckay/clang-avr-libc-interrupt-example > > >> > > >> > > >> > > >> On Thu, Mar 5, 2020 at 4:05 AM Wilhelm Meier > > <wilhelm.meier at hs-kl.de <mailto:wilhelm.meier at hs-kl.de> > > >> <mailto:wilhelm.me...

...   > >> >     > Thanks. >> >     > >> >     > >> >     > Am 11.03.20 um 08:13 schrieb Dylan McKay: >> >     >> Here you go Wilhelm, >> >     >> >> >     >> https://github.com/dylanmckay/clang-avr-libc-interrupt-example >> >     >> >> >     >> >> >     >> >> >     >> On Thu, Mar 5, 2020 at 4:05 AM Wilhelm Meier >> >     <wilhelm.meier at hs-kl.de <mailto:wilhelm.meier at hs-kl.de> >...

...having to change Clang's defaults or have their users specify extra flags to explicitly request them, etc. Out of curiosity/for data/usage/etc - does Sony use aranges? (changing the default when targeting SCE or the like) - Dave > --paulr > > > > *From:* Dylan McKay <me at dylanmckay.io> > *Sent:* Monday, March 16, 2020 1:32 AM > *To:* David Blaikie <dblaikie at gmail.com> > *Cc:* Robinson, Paul <paul.robinson at sony.com>; llvm-dev at lists.llvm.org > *Subject:* Re: [llvm-dev] DWARF .debug_aranges data objects and address > spaces > > > &...

...>>> >     > >>>> >     > >>>> >     > Am 11.03.20 um 08:13 schrieb Dylan McKay: >>>> >     >> Here you go Wilhelm, >>>> >     >> >>>> >     >> https://github.com/dylanmckay/clang-avr-libc-interrupt-example >>>> >     >> >>>> >     >> >>>> >     >> >>>> >     >> On Thu, Mar 5, 2020 at 4:05 AM Wilhelm Meier >>>> >     <wilhelm.meier at hs-kl.de <m...

...e no examples of these in TableGen in tree. The closest I can get is this: set (R1, R0, (umullohi GPR8:$lhs, GPR8:$rhs)) Which fails: Assertion failed: (Ops.size() >= NumSrcResults && "Didn't provide enough results"), function EmitResultCode, file /Users/dylanmckay/projects/llvm/avr-llvm/utils/TableGen/DAGISelMatcherGen.cpp, line 989. 0 libLLVMSupport.dylib 0x0000000108e8c47e llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 46 1 libLLVMSupport.dylib 0x0000000108e8c8c9 PrintStackTraceSignalHandler(void*) + 25 2 libLLVMSupport.dylib 0x0000...

Hello LLVMDevs, I am looking for an example for how to lower LLVM IR to mulsu kind of instruction. I found that AVR back end have such instruction but AVRInstrInfo.td does not define any DAG pattern for which this instruction gets emitted. def MULSURdRr : FMUL2RdRr<1, (outs), (ins GPR8:$lhs, GPR8:$rhs), "mulsu\t$lhs, $rhs", []>, Requires<[SupportsMultiplication]>; Also

Hello Hal, > Add this information to DataLayout and to use that information in relevant places. This sounds like a much better/cleaner idea, thanks! On Wed, Jul 12, 2017 at 1:13 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 07/11/2017 12:54 AM, Dylan McKay via llvm-dev wrote: > > Hello all, I’m looking into solving an AVR-specific issue and would love > to hear

Hello. I was wondering if it is possible to implement placing RO variables within progmem sections. For now it is possible to just use [[gnu::progmem]] and read variables using assembly. My proposal is to: Use those variables as any other, without creating assembly. While reading them, compiler has all necessary knowledge where the variable is and can generate assembly Possible future

I'm not across most of this debug info stuff but I'll stomp in here to confirm that AVR is a Harvard architecture, with separate addressing for the data and program buses via specialized instructions which will load from either one, or the other, but never both. It makes sense that this particular problem would also affect AVR - the backend does have some issues with debug info

> > Hi Reshabh, and congratulations on being selected for GSoC. I haven't > looked at supporting larger than native-width pointers on a target > before. I'd thought that AVR might be relevant (given it uses 16-bit > pointers but has 8-bit GPRs). See the description here > <http://lists.llvm.org/pipermail/llvm-dev/2019-January/129089.html>. > Many thanks Alex,