search for: borisenkov

...on of retl instruction, so I manually exchanged it with ret and reassemble: g++ fpfail.s; ./a.out; echo $? The exit code is 0. This is correct for Intel 80-bit floats but wrong for doubles. What am I do wrong or this is actually a bug or even worse - correct behavior? -- Kind regards, Dmitry Borisenkov -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141007/8d518e8b/attachment.html>

On Oct 7, 2014, at 2:26 PM, Tim Northover <t.p.northover at gmail.com> wrote: > Hi Dmitry, > > On 7 October 2014 10:50, Dmitry Borisenkov <d.borisenkov at samsung.com> wrote: >> fpfail.s:26: Error: invalid instruction suffix for `ret' >> >> I downloaded Intel manual and haven’t found any mention of retl instruction, > > "retl" is the AT&T syntax for the normal "ret" instruct...

Hello, I'd like to write some unit tests which verifies SELECT_CC and BR_CC lowering for ARM target, but I'm almost completely unfamiliar with llvm/Target. How can I get this nodes in DAG? Thanks. -- Kind regards, Dmitry Borisenkov -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140714/6f22bab9/attachment.html>

On Tue, Oct 29, 2019 at 07:19:25PM +0000, Tim Northover via llvm-dev wrote: > On Tue, 29 Oct 2019 at 19:11, Dmitriy Borisenkov via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > 2. Test with a dummy target. It might work if we have a group of contributors who is willing to rewrite and upstream some of their downstream tests as well as to design and implement the target itself. The issue here might be in...

Looks pretty reasonable to me - with test cases. (not sure if dereferenced_type should be defined for a type that's not dereferenceable, though?) On Tue, Jan 23, 2018 at 7:02 AM Dmitriy Borisenkov via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi everyone, > > I have an idea that should allow reducing code duplication in Casting.h > while making llvm::isa, llvm::cast, llvm::dyn_cast, etc more generic. Since > we added unique pointers support for these template func...

Hi everyone, I have an idea that should allow reducing code duplication in Casting.h while making llvm::isa, llvm::cast, llvm::dyn_cast, etc more generic. Since we added unique pointers support for these template functions (see ab480f45cd23c08cb9aa3f427aad072df249135f) I propose to generalize their semantics to deal with any pointer-like type (i.e. dereferenceable and implicitly convertible to

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

On Wed, 2019-10-30 at 15:30 -0700, Chris Lattner via llvm-dev wrote: > > On Oct 30, 2019, at 3:07 AM, Jeroen Dobbelaere via llvm-dev < > > llvm-dev at lists.llvm.org> wrote: > > > > > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of JF > > > Bastien via > > > > [..] > > > Is it relevant to any modern compiler

...produce assembler; we have not specified our object file format yet). Moreover, we have introduced custom IR types to model Tuples, Slices, Builders, Cells from the specification. We are going to do an LLVM update and consider using opaque types before starting to upstream. -- Kind regards, Dmitry Borisenkov -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191023/082336f6/attachment.html>

> On Nov 1, 2019, at 3:41 AM, Dmitriy Borisenkov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > A summary of the discussion so far. > > It seems that there are two possible solutions on how to move forward with non 8 bits byte: > > 1. Commit changes without tests. Chris Lattner, Mikael Holmen, Jeroen Dobbelaere, J...

David, just to clarify a misconception I might have introduced, we do not have linear memory in the sense that all data is stored as a trie. We do support arrays, structures and GEPs, however, as well as all relevant features in C by modeling memory. So regarding concepts of byte, all 5 statements you gave are true for our target. Either due to the specification or because of performance (gas

...d undef (Krzysztof Parzyszek via llvm-dev) > 4. Re: Exception handling support for a target > (Krzysztof Parzyszek via llvm-dev) > 5. Re: Exception handling support for a target > (陳韋任 via llvm-dev) > 6. RFC: Towards unified semantic for casts > (Dmitriy Borisenkov via llvm-dev) > 7. Re: always allow canonicalizing to 8- and 16-bit ops? > (David Green via llvm-dev) > 8. Re: Exception handling support for a target > (Ben Craig via llvm-dev) > 9. [PDB] Error "DIA is not installed on the system" occured in >...

On Sat, Nov 2, 2019 at 12:45 AM Jorg Brown via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Fri, Nov 1, 2019 at 8:40 AM Adrian Prantl via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> > On Nov 1, 2019, at 3:41 AM, Dmitriy Borisenkov via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> > It seems that there are two possible solutions on how to move forward >> with non 8 bits byte: >> > >> > 1. Commit changes without tests. Chris Lattner, Mikael Holmen, Jeroen >> Dobbelaere,...

...2019 at 12:45 AM Jorg Brown via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> On Fri, Nov 1, 2019 at 8:40 AM Adrian Prantl via llvm-dev < >>> llvm-dev at lists.llvm.org> wrote: >>> >>>> > On Nov 1, 2019, at 3:41 AM, Dmitriy Borisenkov via llvm-dev < >>>> llvm-dev at lists.llvm.org> wrote: >>>> > It seems that there are two possible solutions on how to move forward >>>> with non 8 bits byte: >>>> > >>>> > 1. Commit changes without tests. Chris Lattner, Mik...

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