<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/llvm/test/CodeGen/AVR/features, branch users/nico/python-2</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/'/>
<entry>
<title>[AVR,test] Change llc -march= to -mtriple=</title>
<updated>2024-12-15T18:26:33+00:00</updated>
<author>
<name>Fangrui Song</name>
<email>i@maskray.me</email>
</author>
<published>2024-12-15T18:26:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=9ef1d37ffb5f56a9b949a6307bbb16c2ea0130e3'/>
<id>9ef1d37ffb5f56a9b949a6307bbb16c2ea0130e3</id>
<content type='text'>
Similar to 806761a7629df268c8aed49657aeccffa6bca449

-mtriple= specifies the full target triple while -march= merely sets the
architecture part of the default target triple, leaving a target triple which
may not make sense.

Therefore, -march= is error-prone and not recommended for tests without a target
triple. The issue has been benign as we recognize avr-apple-darwin as ELF instead
of rejecting it outrightly.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Similar to 806761a7629df268c8aed49657aeccffa6bca449

-mtriple= specifies the full target triple while -march= merely sets the
architecture part of the default target triple, leaving a target triple which
may not make sense.

Therefore, -march= is error-prone and not recommended for tests without a target
triple. The issue has been benign as we recognize avr-apple-darwin as ELF instead
of rejecting it outrightly.
</pre>
</div>
</content>
</entry>
<entry>
<title>[AVR] Convert tests to opaque pointers (NFC)</title>
<updated>2024-02-05T12:55:50+00:00</updated>
<author>
<name>Nikita Popov</name>
<email>npopov@redhat.com</email>
</author>
<published>2024-02-05T12:55:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=7bdc80f35c325d148b1ddbdfce7dea8c6ba7af84'/>
<id>7bdc80f35c325d148b1ddbdfce7dea8c6ba7af84</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[AVR] Do not use R0/R1 on avrtiny</title>
<updated>2022-11-28T17:05:55+00:00</updated>
<author>
<name>Ayke van Laethem</name>
<email>aykevanlaethem@gmail.com</email>
</author>
<published>2022-11-23T16:24:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=5527b215160cf202431881df3be59ed5c8dabb25'/>
<id>5527b215160cf202431881df3be59ed5c8dabb25</id>
<content type='text'>
This patch makes sure the compiler uses R16/R17 on avrtiny (attiny10
etc) instead of R0/R1.

Some notes:

  * For the NEGW and ROLB instructions, it adds an explicit zero
    register. This is necessary because the zero register is different
    on avrtiny (and InstrInfo Uses lines need a fixed register).
  * Not entirely sure about putting all tests in features/avr-tiny.ll,
    but it doesn't seem like the "target-cpu"="attiny10" attribute
    works.

Updates: https://github.com/llvm/llvm-project/issues/53459

Differential Revision: https://reviews.llvm.org/D138582
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch makes sure the compiler uses R16/R17 on avrtiny (attiny10
etc) instead of R0/R1.

Some notes:

  * For the NEGW and ROLB instructions, it adds an explicit zero
    register. This is necessary because the zero register is different
    on avrtiny (and InstrInfo Uses lines need a fixed register).
  * Not entirely sure about putting all tests in features/avr-tiny.ll,
    but it doesn't seem like the "target-cpu"="attiny10" attribute
    works.

Updates: https://github.com/llvm/llvm-project/issues/53459

Differential Revision: https://reviews.llvm.org/D138582
</pre>
</div>
</content>
</entry>
<entry>
<title>[AVR]  Fix I/O instructions on XMEGA</title>
<updated>2020-05-17T07:46:09+00:00</updated>
<author>
<name>Dylan McKay</name>
<email>me@dylanmckay.io</email>
</author>
<published>2020-05-17T04:25:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=1420f4efbe7ca34355b2dd85d396197d92cd5e3f'/>
<id>1420f4efbe7ca34355b2dd85d396197d92cd5e3f</id>
<content type='text'>
Summary:
On XMEGA, I/O address space is same as data address space - there is no 0x20 offset,
because CPU General Purpose Registers are not mapped in data address space.

From https://en.wikipedia.org/wiki/AVR_microcontrollers
&gt; In the XMEGA variant, the working register file is not mapped into the data address space; as such, it is not possible to treat any of the XMEGA's working registers as though they were SRAM. Instead, the I/O registers are mapped into the data address space starting at the very beginning of the address space.

Reviewers: dylanmckay

Reviewed By: dylanmckay

Subscribers: hiraditya, Jim, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D77207

Patch by Vlastimil Labsky.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Summary:
On XMEGA, I/O address space is same as data address space - there is no 0x20 offset,
because CPU General Purpose Registers are not mapped in data address space.

From https://en.wikipedia.org/wiki/AVR_microcontrollers
&gt; In the XMEGA variant, the working register file is not mapped into the data address space; as such, it is not possible to treat any of the XMEGA's working registers as though they were SRAM. Instead, the I/O registers are mapped into the data address space starting at the very beginning of the address space.

Reviewers: dylanmckay

Reviewed By: dylanmckay

Subscribers: hiraditya, Jim, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D77207

Patch by Vlastimil Labsky.
</pre>
</div>
</content>
</entry>
<entry>
<title>[AVR] Fix the 'avr-tiny.ll' and 'avr25.ll' subtarget feature tests</title>
<updated>2019-06-12T08:31:07+00:00</updated>
<author>
<name>Dylan McKay</name>
<email>me@dylanmckay.io</email>
</author>
<published>2019-06-12T08:31:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=f8b4e60c7f514d70e9b603673fbc351c5df141e1'/>
<id>f8b4e60c7f514d70e9b603673fbc351c5df141e1</id>
<content type='text'>
When these tests were originally written, the middle end would introduce
an unnecessary copy from r24:r23-&gt;GPR16-&gt;r24:r23, and these tests
mistakenly relied on it.

The most optimal codegen for the functions in the test cases before this patch
would be NOPs. This is because the first i16 argument always gets the same register
allocation as an i16 return value in the AVR calling convention.

These tests broke in r362963 when the codegen was improved and the
redundant copy was eliminated. After this, the test functions
were lowered to their optimal form - a 'ret' and nothing else.

This patch prepends an extra i16 operand to each of the test functions
so that a 16-bit copy must be inserted for the program to be correct.

llvm-svn: 363131
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When these tests were originally written, the middle end would introduce
an unnecessary copy from r24:r23-&gt;GPR16-&gt;r24:r23, and these tests
mistakenly relied on it.

The most optimal codegen for the functions in the test cases before this patch
would be NOPs. This is because the first i16 argument always gets the same register
allocation as an i16 return value in the AVR calling convention.

These tests broke in r362963 when the codegen was improved and the
redundant copy was eliminated. After this, the test functions
were lowered to their optimal form - a 'ret' and nothing else.

This patch prepends an extra i16 operand to each of the test functions
so that a 16-bit copy must be inserted for the program to be correct.

llvm-svn: 363131
</pre>
</div>
</content>
</entry>
<entry>
<title>[AVR] Add a selection of CodeGen tests</title>
<updated>2016-11-09T23:46:52+00:00</updated>
<author>
<name>Dylan McKay</name>
<email>dylanmckay34@gmail.com</email>
</author>
<published>2016-11-09T23:46:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=0d4778f841c91985ec5e230949d6827bdc868fa7'/>
<id>0d4778f841c91985ec5e230949d6827bdc868fa7</id>
<content type='text'>
Summary: This adds all of the CodeGen tests which currently pass.

Reviewers: arsenm, kparzysz

Subscribers: japaric, wdng

Differential Revision: https://reviews.llvm.org/D26388

llvm-svn: 286418
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Summary: This adds all of the CodeGen tests which currently pass.

Reviewers: arsenm, kparzysz

Subscribers: japaric, wdng

Differential Revision: https://reviews.llvm.org/D26388

llvm-svn: 286418
</pre>
</div>
</content>
</entry>
</feed>
