Am 03.10.2017 um 11:19 schrieb Georg Icking-Konert:
> hallo Philipp,
>
>> To allow the use of langauges other than C and to evaluate the effect of
>> LLVM optimizations for 8-bit targets, I created an experimental
>> toolchain that allows the use of LLVM clang and opt with 8-bit
>> microcontroller
hallo Philipp,
To allow the use of langauges other than C and to evaluate the effect of
LLVM optimizations for 8-bit targets, I created an experimental
toolchain that allows the use of LLVM clang and opt with 8-bit
microcontrollers via the LLVm C backend and SDCC...
to my understanding the use
On 22.11.2016 21:55, Georg Icking-Konert wrote:
> hello all,
>
> even at the risk of embarrassing myself: can someone please explain
> me the benefit of LLVM+SDCC toolchain vs. the "normal“ SDCC-only
> build? What is the motivation behind? Sorry for my ignorance and
> thanks for a (simple) explana
hello all,
even at the risk of embarrassing myself: can someone please explain me the
benefit of LLVM+SDCC toolchain vs. the "normal“ SDCC-only build? What is the
motivation behind? Sorry for my ignorance and thanks for a (simple)
explanation…!
Regards,
Georg Icking-Konert
--
On 22.11.2016 14:45, alvin albrecht wrote:
>
>>always optimal. Still, we might benefit from some of the optimizations.
>>Have you tried calling opt with vectorizations disabled?
>
> I tried quickly this morning with vectorization disabled on opt and that
> solved the problem. But I ran into anot
>always optimal. Still, we might benefit from some of the optimizations.
>Have you tried calling opt with vectorizations disabled?
I tried quickly this morning with vectorization disabled on opt and that solved
the problem. But I ran into another - sdcc ran out of memory. It gets up to
2GB me
On 13.11.2016 20:14, alvin albrecht wrote:
>
>>> llvm-cbe began wrapping some types into structures as pairs.
>>
>> Did this happen for anything other than arrays? LLVM arrays
>> semantics are different from C (where arrays sometimes decay to
>> pointers, while structs don't). Keep in mind that t
>> llvm-cbe began wrapping some types into
>> structures as pairs.
>
>Did this happen for anything other than arrays? LLVM arrays semantics
>are different from C (where arrays sometimes decay to pointers, while
>structs don't). Keep in mind that the cbe also needs to be able to
>compile LLVM code
On 09.11.2016 04:00, alvin albrecht wrote:
>
> llvm-cbe began wrapping some types into
> structures as pairs.
Did this happen for anything other than arrays? LLVM arrays semantics
are different from C (where arrays sometimes decay to pointers, while
structs don't). Keep in mind that the cbe also
On 09.11.2016 04:00, alvin albrecht wrote:
>
> On 07.11.2016 20:12, Philipp Klaus Krause wrote:
>> On 03.11.2016 12:14, Philipp Klaus Krause wrote:
>>> On 03.11.2016 00:56, alvin albrecht wrote:
> * Install LLVM 3.8 (e.g. using apt-get on Debian).
>> release_38 for cfe.
>
> Much better,
On 07.11.2016 20:12, Philipp Klaus Krause wrote:
> On 03.11.2016 12:14, Philipp Klaus Krause wrote:
>> On 03.11.2016 00:56, alvin albrecht wrote:
>>>
* Install LLVM 3.8 (e.g. using apt-get on Debian).
> release_38 for cfe.
Much better, everything compiles fine.
The llvm-cbe seems to be gear
On 07.11.2016 20:12, Philipp Klaus Krause wrote:
> On 03.11.2016 12:14, Philipp Klaus Krause wrote:
>> On 03.11.2016 00:56, alvin albrecht wrote:
>>>
* Install LLVM 3.8 (e.g. using apt-get on Debian).
* Get my cfe fork (https://github.com/spth/clang) and build it (e.g.
mkdir build; c
On 03.11.2016 12:14, Philipp Klaus Krause wrote:
> On 03.11.2016 00:56, alvin albrecht wrote:
>>
>>> * Install LLVM 3.8 (e.g. using apt-get on Debian).
>>> * Get my cfe fork (https://github.com/spth/clang) and build it (e.g.
>>> mkdir build; cmake ..; make)
>>> * Get the cbe fork (https://github.co
> On my Debian GNU/Linux amd64 system I currently have the following
> llvm-related packages installed:
>
> clang-3.8
> clang-3.8-doc
> libclang-common-3.8-dev
> libclang1-3.6
> libclang1-3.8
> libllvm3.6v5
> libllvm3.7
> libllvm3.7:i386
> libllvm3.8
> libllvm3.8:i386
> llvm-3.8
> llvm-3.8-dev
>
On 04.11.2016 01:50, alvin albrecht wrote:
>
instructions in README.md)
>>>
>>> Is it the master branch if the cfe fork that I should be using?
>>
>> master for cfe, standalone for cbe.
>>
>>> I’m getting a number of errors when compiling with llvm-3.8.0.
>>>
>>
>> I'm using LLVM 3.8.1,
>>> instructions in README.md)
>>
>> Is it the master branch if the cfe fork that I should be using?
>
>master for cfe, standalone for cbe.
>
>> I’m
>> getting a number of errors when compiling with llvm-3.8.0.
>>
>
>I'm using LLVM 3.8.1, and the cfe fork is based on the cfe from 3.8.1.
>But I d
On 03.11.2016 00:56, alvin albrecht wrote:
>
>> * Install LLVM 3.8 (e.g. using apt-get on Debian).
>> * Get my cfe fork (https://github.com/spth/clang) and build it (e.g.
>> mkdir build; cmake ..; make)
>> * Get the cbe fork (https://github.com/Ace17/llvm-cbe) and build it (see
>> instructions in
> * Install LLVM 3.8 (e.g. using apt-get on Debian).
> * Get my cfe fork (https://github.com/spth/clang) and build it (e.g.
> mkdir build; cmake ..; make)
> * Get the cbe fork (https://github.com/Ace17/llvm-cbe) and build it (see
> instructions in README.md)
Is it the master branch if the cfe for
On 21.09.2016 17:27, Philipp Klaus Krause wrote:
> To allow the use of langauges other than C and to evaluate the effect of
> LLVM optimizations for 8-bit targets, I created an experimental
> toolchain that allows the use of LLVM clang and opt with 8-bit
> microcontrollers via the LLVm C backend an
To allow the use of langauges other than C and to evaluate the effect of
LLVM optimizations for 8-bit targets, I created an experimental
toolchain that allows the use of LLVM clang and opt with 8-bit
microcontrollers via the LLVm C backend and SDCC.
The toolchain is still in a very early stage and
20 matches
Mail list logo
