Target-specific defaults for LLVM tools?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Target-specific defaults for LLVM tools?

Dario Domizioli
Hello, LLVM.

We'd like to start a discussion about what would be the best way of
supporting target-specific defaults for options in the LLVM tools.

Problem description
-------------------

LLVM strives to be a generic compiler and it has a lot of code generation
options which are (rightly) not linked to the target triple.
However, some target triples do impose hard requirements for such options. For
example, PS4 requires the relocation model to be PIC. Cross-compilers for
specific target systems are likely to have similar restrictions.

One very effective way to ensure that users of Clang/LLVM don't misuse the
tools by passing the wrong options is to set the default values for those
options in the cross-compiler once the target triple is known. This has the
following rationale:

- Correctness: the user must be able to generate correct code for the target
  in the default workflow (with or without optimizations).
- Performance: the user should be able to generate good code for the target
  in the default workflow with optimizations enabled.
- Usability: although the default workflow could potentially be defined as
  "sorry, but you must pass options X, Y and Z to the tools", obviously it would
  be easier if it did not require such esoteric options.

And of course, from a company's point of view:

- Commercial reasons: if a tool is released commercially, the user expects such
  commercial product to work "out of the box" for the target system.

This is very easy to do in Clang, as the driver does the job of "dispatching"
the correct command line options to subsequent invocations of tools. Because of
the driver being the "middle man", it can parse the options, understand what the
target triple is, and invoke other tools accordingly (i.e. actively adding an
option, or erroring out upon encountering an invalid set of options).

A vendor can set the default target triple for Clang even at build time, and
this approach seems to not cause any trouble in the Clang tests (which don't get
as far as checking the output assembly). So for Clang the problem is solved to a
certain degree.

However, issues start to pop up when we consider all the other tools (opt, llc,
and so on) and the complications of having for example a "cross-llc". Usage of
such tools is becoming increasingly likely thanks to the existence of other
tools and frontends which can generate LLVM IR. Some crazy people might even try
to write IR instead of C++! :-)

First of all, overriding the defaults based on the triple is harder in LLVM
tools, because of how the cl::opt options work. If you consider llc, it
determines the triple in this sequence:

- Parse the IR and extract the triple if present.
- If there's a triple on the command line, override the IR triple.
- If no triple was found by either method, use the default triple.

This process is performed in the compileModule() function, which happens way
after the cl::init initializers for the cl::opt option defaults, and shortly
after the cl::ParseCommandLineOptions() call. If the value of some option needs
to be changed _after_ the triple has been determined, additional work has to be
performed to tweak the cl::opt options on the fly, but only if they had not
already been set on the command line (which would mean the user explicitly
wanted a non-default value). It would be quite ugly, although doable.

The real problem, however, is that tools are used not only by the end user, but
also extensively by the LLVM tests that check the output assembly.
Currently, there is a non-trivial number of LLVM tests that do not set the full
triple, but only parts of it, and then rely on specific default code generation
options. In the past, some defaults have been locked down as opposed to being
auto-detected (for example, -mcpu=generic) specifically for the purpose of
making tests stable and correct for cross-compilers.

Changing the code to override the defaults for opt, llc, and so on based on the
target triple can make some tests fail, because it would reinstate the same
problems we had before locking down such defaults. Of course, such a change
could be kept private and out of the open-source tree, and the tests could be
modified accordingly. However, it is clear that it could become a large burden
to support these private changes when new tests are constantly added to the
codebase.

We would like to start a discussion with the community about how best to support
the use case of "target-specific defaults for LLVM tools", especially in the
case of cross-compiling tools. Maybe somebody else is running into our same
use-case.
And this could even prove to be tied to the cl::opt reworking that was going on
a while ago, so new requirements / limitations / ideas might emerge.

We have identified a few approaches that could serve as the starting point of a
discussion. I will briefly outline them below. We don't want to push for any of
them, we just want to discuss them. There could even be more effective ways of
solving the problem, which is why we are interested in having this discussion
here.


A - Fixed option defaults, irrelevant default triple logic
----------------------------------------------------------

I believe this is the current situation, possibly caused by how cl::opt works.
This alternative assumes that:

- There is no functionality in the open-source tree to change the defaults based
  on the target triple.
- Vendors may or may not change the default triple in their cross-compilers.

If a vendor wants to both change a tool to have a specific default triple, and
cause option defaults to depend on the triple, it is the vendor's responsibility
to adapt failing tests, and changes will have to be kept private. If a vendor
tried to push them onto the community ("yes, this -mcpu=generic in the test is
totally unnecessary, but can we have it in tree?"), such a change would never
pass a review.

If this approach is chosen, then vendors will have to maintain private changes,
but the state of the LLVM tests in the open-source tree will be consistent and
there will be no target-specific code to override option defaults.


B - Triple-based option defaults, variable default triple logic
---------------------------------------------------------------

This alternative is at the other end of the spectrum and it assumes that:

- There is some functionality (a new API in llvm::cl?) in the open-source tree
  to override the defaults based on the target triple.
- The default target triple can be freely changed in cross-compilers, with
  impunity.

As described above, this would cause problems to some existing tests. It could
be argued though that, if a test is unstable with respect to code generation
options, then it should specify all options that it actually requires in order
to run properly.
This would mean that tests must specify a target triple in the RUN lines or in
the IR, otherwise they cannot assume that the code will be generated as
expected.

This puts a burden on the test implementors, but could it be argued that this is
technically correct? Shouldn't tests be robust? On the other hand, if tests had
to specify a target triple, wouldn't this reduce coverage (as they'd be testing
a single target as opposed to many)?

If this approach was chosen, then a good number of LLVM tests in the open-source
tree would need to be adapted, but vendors could be free to implement their own
defaults and set the default triple without significant consequences.


C - Triple-based option defaults, fixed default triple logic
------------------------------------------------------------

This alternative assumes that:

- There is some functionality (a new API in llvm::cl?) in the open-source tree
  to override the defaults based on the target triple.
- Vendors are NOT free to change the logic determining the default triple.
- The default triple is inferred by some fixed logic, which is test-friendly.

There is code in the Clang driver that parses the program name to identify a
prefix that is used to determine the target triple. For example, I seem to
understand that "x86_64-scei-ps4-clang" would indicate a Clang which has a PS4
target triple by default.
Opt, llc, and similar tools do not support anything of the sort, so at the
moment the default target triple cannot be selected with the same approach.

Anyway, consider the case where option defaults are set based on the target
triple, but the default triple can be inferred from the name prefix, just as
Clang does; if no such prefix is found, the defaulting falls back to what we do
currently. This allows tests with RUN lines running "llc" to just use the triple
that we currently use, and therefore all existing open-source tests will
continue to work.

At the same time, a vendor could release a tool with a name prefix and reap the
benefits of having the desired defaults; and to make it convenient for the user,
a symlink (or something more complex on Windows) could easily be used.

If this approach was chosen, vendor-specific tests which expect the vendor
defaults would have to somehow rename the tool on the fly before running it; or
maybe they could change the build process to produce both an "llc" and a
"<triple>-llc" executables. Also vendors would need to release the renamed
tools, but this often happens anyway with cross-compilers. This pushes some
burden on the vendor, but it is much less than maintaining a lot of private
changes to the open-source code and tests.

What does the community think?
Discuss. :-)

Cheers,
    Dario Domizioli
    SN Systems - Sony Computer Entertainment Group



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Target-specific defaults for LLVM tools?

Owen Anderson-2

On Mar 17, 2015, at 11:13 AM, Dario Domizioli <[hidden email]> wrote:

What does the community think?
Discuss. :-)

Devil’s advocate: opt, llc, lli, etc. are development/debugging tools for LLVM developers, not for end users, and the project optimizes their functionality for that use case.

—Owen

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Target-specific defaults for LLVM tools?

Eric Christopher


On Tue, Mar 17, 2015 at 11:44 AM Owen Anderson <[hidden email]> wrote:

On Mar 17, 2015, at 11:13 AM, Dario Domizioli <[hidden email]> wrote:

What does the community think?
Discuss. :-)

Devil’s advocate: opt, llc, lli, etc. are development/debugging tools for LLVM developers, not for end users, and the project optimizes their functionality for that use case.


+1 :)

-eric
 
—Owen
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Target-specific defaults for LLVM tools?

Anton Korobeynikov-2
In reply to this post by Dario Domizioli
> However, issues start to pop up when we consider all the other tools (opt,
> llc,
> and so on) and the complications of having for example a "cross-llc". Usage
> of
> such tools is becoming increasingly likely thanks to the existence of other
> tools and frontends which can generate LLVM IR. Some crazy people might even
> try
> to write IR instead of C++! :-)
llc / opt and similar tools are intended for LLVM developer use and
should never be exposed to end-user. Therefore, things like
"cross-llc" and similar do not make any sense.

If, for some particular weird reason, there is need for e.g. 'opt'
functionality to be provided to users, then a new tool with clear
command line should be developed implementing the necessary
functionality.

> Currently, there is a non-trivial number of LLVM tests that do not set the full
> triple, but only parts of it, and then rely on specific default code generation
> options.
In most cases this should be considered as a bug - the test should be
precise and therefore ought to be fixed.

--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Target-specific defaults for LLVM tools?

Eric Christopher


On Tue, Mar 17, 2015 at 12:16 PM Anton Korobeynikov <[hidden email]> wrote:
> However, issues start to pop up when we consider all the other tools (opt,
> llc,
> and so on) and the complications of having for example a "cross-llc". Usage
> of
> such tools is becoming increasingly likely thanks to the existence of other
> tools and frontends which can generate LLVM IR. Some crazy people might even
> try
> to write IR instead of C++! :-)
llc / opt and similar tools are intended for LLVM developer use and
should never be exposed to end-user. Therefore, things like
"cross-llc" and similar do not make any sense.

If, for some particular weird reason, there is need for e.g. 'opt'
functionality to be provided to users, then a new tool with clear
command line should be developed implementing the necessary
functionality.

> Currently, there is a non-trivial number of LLVM tests that do not set the full
> triple, but only parts of it, and then rely on specific default code generation
> options.
In most cases this should be considered as a bug - the test should be
precise and therefore ought to be fixed.


To elaborate more here:

a) It's probably a bug in the test, however,
b) It may be that the test is considered generic enough to be for all x86 and there's something else going a little weird.

There's enough b that it's still probably a case by case basis.

-eric 

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Target-specific defaults for LLVM tools?

Sean Silva-2
In reply to this post by Dario Domizioli


On Tue, Mar 17, 2015 at 11:13 AM, Dario Domizioli <[hidden email]> wrote:
Hello, LLVM.

We'd like to start a discussion about what would be the best way of
supporting target-specific defaults for options in the LLVM tools.

Problem description
-------------------

LLVM strives to be a generic compiler and it has a lot of code generation
options which are (rightly) not linked to the target triple.
However, some target triples do impose hard requirements for such options. For
example, PS4 requires the relocation model to be PIC. Cross-compilers for
specific target systems are likely to have similar restrictions.

One very effective way to ensure that users of Clang/LLVM don't misuse the
tools by passing the wrong options is to set the default values for those
options in the cross-compiler once the target triple is known. This has the
following rationale:

- Correctness: the user must be able to generate correct code for the target
  in the default workflow (with or without optimizations).
- Performance: the user should be able to generate good code for the target
  in the default workflow with optimizations enabled.
- Usability: although the default workflow could potentially be defined as
  "sorry, but you must pass options X, Y and Z to the tools", obviously it would
  be easier if it did not require such esoteric options.

And of course, from a company's point of view:

- Commercial reasons: if a tool is released commercially, the user expects such
  commercial product to work "out of the box" for the target system.

This is very easy to do in Clang, as the driver does the job of "dispatching"
the correct command line options to subsequent invocations of tools. Because of
the driver being the "middle man", it can parse the options, understand what the
target triple is, and invoke other tools accordingly (i.e. actively adding an
option, or erroring out upon encountering an invalid set of options).

A vendor can set the default target triple for Clang even at build time, and
this approach seems to not cause any trouble in the Clang tests (which don't get
as far as checking the output assembly). So for Clang the problem is solved to a
certain degree.

However, issues start to pop up when we consider all the other tools (opt, llc,
and so on) and the complications of having for example a "cross-llc". Usage of
such tools is becoming increasingly likely thanks to the existence of other
tools and frontends which can generate LLVM IR. Some crazy people might even try
to write IR instead of C++! :-)

First of all, overriding the defaults based on the triple is harder in LLVM
tools, because of how the cl::opt options work. If you consider llc, it
determines the triple in this sequence:

- Parse the IR and extract the triple if present.
- If there's a triple on the command line, override the IR triple.
- If no triple was found by either method, use the default triple.

This process is performed in the compileModule() function, which happens way
after the cl::init initializers for the cl::opt option defaults, and shortly
after the cl::ParseCommandLineOptions() call. If the value of some option needs
to be changed _after_ the triple has been determined, additional work has to be
performed to tweak the cl::opt options on the fly, but only if they had not
already been set on the command line (which would mean the user explicitly
wanted a non-default value). It would be quite ugly, although doable.

The real problem, however, is that tools are used not only by the end user, but
also extensively by the LLVM tests that check the output assembly.

You have this completely backwards, and then some. The use case for these tools for testing is not "also". That is the only current use case that they are developed for. I'm not sure where you got the impression that they are meant to be used by end users, but that is just completely, flat-out incorrect.

-- Sean Silva
 
Currently, there is a non-trivial number of LLVM tests that do not set the full
triple, but only parts of it, and then rely on specific default code generation
options. In the past, some defaults have been locked down as opposed to being
auto-detected (for example, -mcpu=generic) specifically for the purpose of
making tests stable and correct for cross-compilers.

Changing the code to override the defaults for opt, llc, and so on based on the
target triple can make some tests fail, because it would reinstate the same
problems we had before locking down such defaults. Of course, such a change
could be kept private and out of the open-source tree, and the tests could be
modified accordingly. However, it is clear that it could become a large burden
to support these private changes when new tests are constantly added to the
codebase.

We would like to start a discussion with the community about how best to support
the use case of "target-specific defaults for LLVM tools", especially in the
case of cross-compiling tools. Maybe somebody else is running into our same
use-case.
And this could even prove to be tied to the cl::opt reworking that was going on
a while ago, so new requirements / limitations / ideas might emerge.

We have identified a few approaches that could serve as the starting point of a
discussion. I will briefly outline them below. We don't want to push for any of
them, we just want to discuss them. There could even be more effective ways of
solving the problem, which is why we are interested in having this discussion
here.


A - Fixed option defaults, irrelevant default triple logic
----------------------------------------------------------

I believe this is the current situation, possibly caused by how cl::opt works.
This alternative assumes that:

- There is no functionality in the open-source tree to change the defaults based
  on the target triple.
- Vendors may or may not change the default triple in their cross-compilers.

If a vendor wants to both change a tool to have a specific default triple, and
cause option defaults to depend on the triple, it is the vendor's responsibility
to adapt failing tests, and changes will have to be kept private. If a vendor
tried to push them onto the community ("yes, this -mcpu=generic in the test is
totally unnecessary, but can we have it in tree?"), such a change would never
pass a review.

If this approach is chosen, then vendors will have to maintain private changes,
but the state of the LLVM tests in the open-source tree will be consistent and
there will be no target-specific code to override option defaults.


B - Triple-based option defaults, variable default triple logic
---------------------------------------------------------------

This alternative is at the other end of the spectrum and it assumes that:

- There is some functionality (a new API in llvm::cl?) in the open-source tree
  to override the defaults based on the target triple.
- The default target triple can be freely changed in cross-compilers, with
  impunity.

As described above, this would cause problems to some existing tests. It could
be argued though that, if a test is unstable with respect to code generation
options, then it should specify all options that it actually requires in order
to run properly.
This would mean that tests must specify a target triple in the RUN lines or in
the IR, otherwise they cannot assume that the code will be generated as
expected.

This puts a burden on the test implementors, but could it be argued that this is
technically correct? Shouldn't tests be robust? On the other hand, if tests had
to specify a target triple, wouldn't this reduce coverage (as they'd be testing
a single target as opposed to many)?

If this approach was chosen, then a good number of LLVM tests in the open-source
tree would need to be adapted, but vendors could be free to implement their own
defaults and set the default triple without significant consequences.


C - Triple-based option defaults, fixed default triple logic
------------------------------------------------------------

This alternative assumes that:

- There is some functionality (a new API in llvm::cl?) in the open-source tree
  to override the defaults based on the target triple.
- Vendors are NOT free to change the logic determining the default triple.
- The default triple is inferred by some fixed logic, which is test-friendly.

There is code in the Clang driver that parses the program name to identify a
prefix that is used to determine the target triple. For example, I seem to
understand that "x86_64-scei-ps4-clang" would indicate a Clang which has a PS4
target triple by default.
Opt, llc, and similar tools do not support anything of the sort, so at the
moment the default target triple cannot be selected with the same approach.

Anyway, consider the case where option defaults are set based on the target
triple, but the default triple can be inferred from the name prefix, just as
Clang does; if no such prefix is found, the defaulting falls back to what we do
currently. This allows tests with RUN lines running "llc" to just use the triple
that we currently use, and therefore all existing open-source tests will
continue to work.

At the same time, a vendor could release a tool with a name prefix and reap the
benefits of having the desired defaults; and to make it convenient for the user,
a symlink (or something more complex on Windows) could easily be used.

If this approach was chosen, vendor-specific tests which expect the vendor
defaults would have to somehow rename the tool on the fly before running it; or
maybe they could change the build process to produce both an "llc" and a
"<triple>-llc" executables. Also vendors would need to release the renamed
tools, but this often happens anyway with cross-compilers. This pushes some
burden on the vendor, but it is much less than maintaining a lot of private
changes to the open-source code and tests.

What does the community think?
Discuss. :-)

Cheers,
    Dario Domizioli
    SN Systems - Sony Computer Entertainment Group



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Target-specific defaults for LLVM tools?

Chris Bieneman
Not to pile on the “LLVM tools are for debugging” bandwagon too hard here, but I’m pretty sure the clang driver can be used on source, IR, and disassembly. People shouldn’t be using llc and opt, instead they should just pass the IR files to clang.

Then clang can set the right target-specific defaults based on the clang flags.

That seems like a much more reasonable approach to the problem to me.

-Chris

On Mar 17, 2015, at 12:26 PM, Sean Silva <[hidden email]> wrote:



On Tue, Mar 17, 2015 at 11:13 AM, Dario Domizioli <[hidden email]> wrote:
Hello, LLVM.

We'd like to start a discussion about what would be the best way of
supporting target-specific defaults for options in the LLVM tools.

Problem description
-------------------

LLVM strives to be a generic compiler and it has a lot of code generation
options which are (rightly) not linked to the target triple.
However, some target triples do impose hard requirements for such options. For
example, PS4 requires the relocation model to be PIC. Cross-compilers for
specific target systems are likely to have similar restrictions.

One very effective way to ensure that users of Clang/LLVM don't misuse the
tools by passing the wrong options is to set the default values for those
options in the cross-compiler once the target triple is known. This has the
following rationale:

- Correctness: the user must be able to generate correct code for the target
  in the default workflow (with or without optimizations).
- Performance: the user should be able to generate good code for the target
  in the default workflow with optimizations enabled.
- Usability: although the default workflow could potentially be defined as
  "sorry, but you must pass options X, Y and Z to the tools", obviously it would
  be easier if it did not require such esoteric options.

And of course, from a company's point of view:

- Commercial reasons: if a tool is released commercially, the user expects such
  commercial product to work "out of the box" for the target system.

This is very easy to do in Clang, as the driver does the job of "dispatching"
the correct command line options to subsequent invocations of tools. Because of
the driver being the "middle man", it can parse the options, understand what the
target triple is, and invoke other tools accordingly (i.e. actively adding an
option, or erroring out upon encountering an invalid set of options).

A vendor can set the default target triple for Clang even at build time, and
this approach seems to not cause any trouble in the Clang tests (which don't get
as far as checking the output assembly). So for Clang the problem is solved to a
certain degree.

However, issues start to pop up when we consider all the other tools (opt, llc,
and so on) and the complications of having for example a "cross-llc". Usage of
such tools is becoming increasingly likely thanks to the existence of other
tools and frontends which can generate LLVM IR. Some crazy people might even try
to write IR instead of C++! :-)

First of all, overriding the defaults based on the triple is harder in LLVM
tools, because of how the cl::opt options work. If you consider llc, it
determines the triple in this sequence:

- Parse the IR and extract the triple if present.
- If there's a triple on the command line, override the IR triple.
- If no triple was found by either method, use the default triple.

This process is performed in the compileModule() function, which happens way
after the cl::init initializers for the cl::opt option defaults, and shortly
after the cl::ParseCommandLineOptions() call. If the value of some option needs
to be changed _after_ the triple has been determined, additional work has to be
performed to tweak the cl::opt options on the fly, but only if they had not
already been set on the command line (which would mean the user explicitly
wanted a non-default value). It would be quite ugly, although doable.

The real problem, however, is that tools are used not only by the end user, but
also extensively by the LLVM tests that check the output assembly.

You have this completely backwards, and then some. The use case for these tools for testing is not "also". That is the only current use case that they are developed for. I'm not sure where you got the impression that they are meant to be used by end users, but that is just completely, flat-out incorrect.

-- Sean Silva
 
Currently, there is a non-trivial number of LLVM tests that do not set the full
triple, but only parts of it, and then rely on specific default code generation
options. In the past, some defaults have been locked down as opposed to being
auto-detected (for example, -mcpu=generic) specifically for the purpose of
making tests stable and correct for cross-compilers.

Changing the code to override the defaults for opt, llc, and so on based on the
target triple can make some tests fail, because it would reinstate the same
problems we had before locking down such defaults. Of course, such a change
could be kept private and out of the open-source tree, and the tests could be
modified accordingly. However, it is clear that it could become a large burden
to support these private changes when new tests are constantly added to the
codebase.

We would like to start a discussion with the community about how best to support
the use case of "target-specific defaults for LLVM tools", especially in the
case of cross-compiling tools. Maybe somebody else is running into our same
use-case.
And this could even prove to be tied to the cl::opt reworking that was going on
a while ago, so new requirements / limitations / ideas might emerge.

We have identified a few approaches that could serve as the starting point of a
discussion. I will briefly outline them below. We don't want to push for any of
them, we just want to discuss them. There could even be more effective ways of
solving the problem, which is why we are interested in having this discussion
here.


A - Fixed option defaults, irrelevant default triple logic
----------------------------------------------------------

I believe this is the current situation, possibly caused by how cl::opt works.
This alternative assumes that:

- There is no functionality in the open-source tree to change the defaults based
  on the target triple.
- Vendors may or may not change the default triple in their cross-compilers.

If a vendor wants to both change a tool to have a specific default triple, and
cause option defaults to depend on the triple, it is the vendor's responsibility
to adapt failing tests, and changes will have to be kept private. If a vendor
tried to push them onto the community ("yes, this -mcpu=generic in the test is
totally unnecessary, but can we have it in tree?"), such a change would never
pass a review.

If this approach is chosen, then vendors will have to maintain private changes,
but the state of the LLVM tests in the open-source tree will be consistent and
there will be no target-specific code to override option defaults.


B - Triple-based option defaults, variable default triple logic
---------------------------------------------------------------

This alternative is at the other end of the spectrum and it assumes that:

- There is some functionality (a new API in llvm::cl?) in the open-source tree
  to override the defaults based on the target triple.
- The default target triple can be freely changed in cross-compilers, with
  impunity.

As described above, this would cause problems to some existing tests. It could
be argued though that, if a test is unstable with respect to code generation
options, then it should specify all options that it actually requires in order
to run properly.
This would mean that tests must specify a target triple in the RUN lines or in
the IR, otherwise they cannot assume that the code will be generated as
expected.

This puts a burden on the test implementors, but could it be argued that this is
technically correct? Shouldn't tests be robust? On the other hand, if tests had
to specify a target triple, wouldn't this reduce coverage (as they'd be testing
a single target as opposed to many)?

If this approach was chosen, then a good number of LLVM tests in the open-source
tree would need to be adapted, but vendors could be free to implement their own
defaults and set the default triple without significant consequences.


C - Triple-based option defaults, fixed default triple logic
------------------------------------------------------------

This alternative assumes that:

- There is some functionality (a new API in llvm::cl?) in the open-source tree
  to override the defaults based on the target triple.
- Vendors are NOT free to change the logic determining the default triple.
- The default triple is inferred by some fixed logic, which is test-friendly.

There is code in the Clang driver that parses the program name to identify a
prefix that is used to determine the target triple. For example, I seem to
understand that "x86_64-scei-ps4-clang" would indicate a Clang which has a PS4
target triple by default.
Opt, llc, and similar tools do not support anything of the sort, so at the
moment the default target triple cannot be selected with the same approach.

Anyway, consider the case where option defaults are set based on the target
triple, but the default triple can be inferred from the name prefix, just as
Clang does; if no such prefix is found, the defaulting falls back to what we do
currently. This allows tests with RUN lines running "llc" to just use the triple
that we currently use, and therefore all existing open-source tests will
continue to work.

At the same time, a vendor could release a tool with a name prefix and reap the
benefits of having the desired defaults; and to make it convenient for the user,
a symlink (or something more complex on Windows) could easily be used.

If this approach was chosen, vendor-specific tests which expect the vendor
defaults would have to somehow rename the tool on the fly before running it; or
maybe they could change the build process to produce both an "llc" and a
"<triple>-llc" executables. Also vendors would need to release the renamed
tools, but this often happens anyway with cross-compilers. This pushes some
burden on the vendor, but it is much less than maintaining a lot of private
changes to the open-source code and tests.

What does the community think?
Discuss. :-)

Cheers,
    Dario Domizioli
    SN Systems - Sony Computer Entertainment Group



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Target-specific defaults for LLVM tools?

David Jones
In reply to this post by Owen Anderson-2
What is the preferred method for compiler (frontend) developers to optimize and generate target machine code from IR?

At one point I found a tutorial that recommended simply dumping the IR to a file and spawning llc to do the job.

Up until now I have "manually" created a TargetMachine, PassManager, etc. to generate my object code. The initial version of my code was cribbed from llc for LLVM 3.2, and has since been updated for 3.5.1.

However, with every new release of LLVM, the API to the backend optimization and code generation passes changes.  The changes from 3.5.1 to 3.6 are quite significant. If I'm lucky, the impact of a change is that my C++ code refuses to compile, and I have to fix. If I'm unlucky, the impact may be that my code compiles and runs, but LLVM works suboptimally - perhaps some optimizations don't happen. (This can happen if a newer API expects me to do some step which was not required in earlier releases, and there is no assert to catch it.)

As an alternative, I am seriously considering "simply dumping the IR to a file and spawning llc" to perform my backend work. The API to create IR is much more stable than the API to do useful things with it. Furthermore, it's a lot easier to manually debug IR that has been dumped to a file. Finally, I can spawn multiple, independent, concurrent invocations of llc on a multi-core machine. I needn't worry about concurrency, as the standard Linux fork/waitpid type calls will suffice. Given that 90% of my runtime is spent inside LLVM, I get 90% of the benefit of a fully concurrent design with almost zero work.

But now it seems that this usage model is frowned upon.

What is the recommended usage model?


On Tue, Mar 17, 2015 at 2:32 PM, Owen Anderson <[hidden email]> wrote:

On Mar 17, 2015, at 11:13 AM, Dario Domizioli <[hidden email]> wrote:

What does the community think?
Discuss. :-)

Devil’s advocate: opt, llc, lli, etc. are development/debugging tools for LLVM developers, not for end users, and the project optimizes their functionality for that use case.

—Owen

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Target-specific defaults for LLVM tools?

Steve King
In reply to this post by Chris Bieneman
Doesn't count for much, but I'm sympathetic to Dario's concern with
cl::opt and clang defaults.  In one large out-of-tree project,
colleagues decided to create their own driver to handle the required
customization of the build process and options.

If clang is the user's one stop shop, here's one such cross compiler
example I'd like to understand better:  GNU binutils has no clue of my
target.  Instead of trying to use gas, how should GNU-less targets
enable clang invoke llvm-mc to assemble?


On Tue, Mar 17, 2015 at 1:14 PM, Chris Bieneman <[hidden email]> wrote:

> Not to pile on the “LLVM tools are for debugging” bandwagon too hard here,
> but I’m pretty sure the clang driver can be used on source, IR, and
> disassembly. People shouldn’t be using llc and opt, instead they should just
> pass the IR files to clang.
>
> Then clang can set the right target-specific defaults based on the clang
> flags.
>
> That seems like a much more reasonable approach to the problem to me.
>
> -Chris
>
> On Mar 17, 2015, at 12:26 PM, Sean Silva <[hidden email]> wrote:
>
>
>
> On Tue, Mar 17, 2015 at 11:13 AM, Dario Domizioli
> <[hidden email]> wrote:
>>
>> Hello, LLVM.
>>
>> We'd like to start a discussion about what would be the best way of
>> supporting target-specific defaults for options in the LLVM tools.
>>
>> Problem description
>> -------------------
>>
>> LLVM strives to be a generic compiler and it has a lot of code generation
>> options which are (rightly) not linked to the target triple.
>> However, some target triples do impose hard requirements for such options.
>> For
>> example, PS4 requires the relocation model to be PIC. Cross-compilers for
>> specific target systems are likely to have similar restrictions.
>>
>> One very effective way to ensure that users of Clang/LLVM don't misuse the
>> tools by passing the wrong options is to set the default values for those
>> options in the cross-compiler once the target triple is known. This has
>> the
>> following rationale:
>>
>> - Correctness: the user must be able to generate correct code for the
>> target
>>   in the default workflow (with or without optimizations).
>> - Performance: the user should be able to generate good code for the
>> target
>>   in the default workflow with optimizations enabled.
>> - Usability: although the default workflow could potentially be defined as
>>   "sorry, but you must pass options X, Y and Z to the tools", obviously it
>> would
>>   be easier if it did not require such esoteric options.
>>
>> And of course, from a company's point of view:
>>
>> - Commercial reasons: if a tool is released commercially, the user expects
>> such
>>   commercial product to work "out of the box" for the target system.
>>
>> This is very easy to do in Clang, as the driver does the job of
>> "dispatching"
>> the correct command line options to subsequent invocations of tools.
>> Because of
>> the driver being the "middle man", it can parse the options, understand
>> what the
>> target triple is, and invoke other tools accordingly (i.e. actively adding
>> an
>> option, or erroring out upon encountering an invalid set of options).
>>
>> A vendor can set the default target triple for Clang even at build time,
>> and
>> this approach seems to not cause any trouble in the Clang tests (which
>> don't get
>> as far as checking the output assembly). So for Clang the problem is
>> solved to a
>> certain degree.
>>
>> However, issues start to pop up when we consider all the other tools (opt,
>> llc,
>> and so on) and the complications of having for example a "cross-llc".
>> Usage of
>> such tools is becoming increasingly likely thanks to the existence of
>> other
>> tools and frontends which can generate LLVM IR. Some crazy people might
>> even try
>> to write IR instead of C++! :-)
>>
>> First of all, overriding the defaults based on the triple is harder in
>> LLVM
>> tools, because of how the cl::opt options work. If you consider llc, it
>> determines the triple in this sequence:
>>
>> - Parse the IR and extract the triple if present.
>> - If there's a triple on the command line, override the IR triple.
>> - If no triple was found by either method, use the default triple.
>>
>> This process is performed in the compileModule() function, which happens
>> way
>> after the cl::init initializers for the cl::opt option defaults, and
>> shortly
>> after the cl::ParseCommandLineOptions() call. If the value of some option
>> needs
>> to be changed _after_ the triple has been determined, additional work has
>> to be
>> performed to tweak the cl::opt options on the fly, but only if they had
>> not
>> already been set on the command line (which would mean the user explicitly
>> wanted a non-default value). It would be quite ugly, although doable.
>>
>> The real problem, however, is that tools are used not only by the end
>> user, but
>> also extensively by the LLVM tests that check the output assembly.
>
>
> You have this completely backwards, and then some. The use case for these
> tools for testing is not "also". That is the only current use case that they
> are developed for. I'm not sure where you got the impression that they are
> meant to be used by end users, but that is just completely, flat-out
> incorrect.
>
> -- Sean Silva
>
>>
>> Currently, there is a non-trivial number of LLVM tests that do not set the
>> full
>> triple, but only parts of it, and then rely on specific default code
>> generation
>> options. In the past, some defaults have been locked down as opposed to
>> being
>> auto-detected (for example, -mcpu=generic) specifically for the purpose of
>> making tests stable and correct for cross-compilers.
>>
>> Changing the code to override the defaults for opt, llc, and so on based
>> on the
>> target triple can make some tests fail, because it would reinstate the
>> same
>> problems we had before locking down such defaults. Of course, such a
>> change
>> could be kept private and out of the open-source tree, and the tests could
>> be
>> modified accordingly. However, it is clear that it could become a large
>> burden
>> to support these private changes when new tests are constantly added to
>> the
>> codebase.
>>
>> We would like to start a discussion with the community about how best to
>> support
>> the use case of "target-specific defaults for LLVM tools", especially in
>> the
>> case of cross-compiling tools. Maybe somebody else is running into our
>> same
>> use-case.
>> And this could even prove to be tied to the cl::opt reworking that was
>> going on
>> a while ago, so new requirements / limitations / ideas might emerge.
>>
>> We have identified a few approaches that could serve as the starting point
>> of a
>> discussion. I will briefly outline them below. We don't want to push for
>> any of
>> them, we just want to discuss them. There could even be more effective
>> ways of
>> solving the problem, which is why we are interested in having this
>> discussion
>> here.
>>
>>
>> A - Fixed option defaults, irrelevant default triple logic
>> ----------------------------------------------------------
>>
>> I believe this is the current situation, possibly caused by how cl::opt
>> works.
>> This alternative assumes that:
>>
>> - There is no functionality in the open-source tree to change the defaults
>> based
>>   on the target triple.
>> - Vendors may or may not change the default triple in their
>> cross-compilers.
>>
>> If a vendor wants to both change a tool to have a specific default triple,
>> and
>> cause option defaults to depend on the triple, it is the vendor's
>> responsibility
>> to adapt failing tests, and changes will have to be kept private. If a
>> vendor
>> tried to push them onto the community ("yes, this -mcpu=generic in the
>> test is
>> totally unnecessary, but can we have it in tree?"), such a change would
>> never
>> pass a review.
>>
>> If this approach is chosen, then vendors will have to maintain private
>> changes,
>> but the state of the LLVM tests in the open-source tree will be consistent
>> and
>> there will be no target-specific code to override option defaults.
>>
>>
>> B - Triple-based option defaults, variable default triple logic
>> ---------------------------------------------------------------
>>
>> This alternative is at the other end of the spectrum and it assumes that:
>>
>> - There is some functionality (a new API in llvm::cl?) in the open-source
>> tree
>>   to override the defaults based on the target triple.
>> - The default target triple can be freely changed in cross-compilers, with
>>   impunity.
>>
>> As described above, this would cause problems to some existing tests. It
>> could
>> be argued though that, if a test is unstable with respect to code
>> generation
>> options, then it should specify all options that it actually requires in
>> order
>> to run properly.
>> This would mean that tests must specify a target triple in the RUN lines
>> or in
>> the IR, otherwise they cannot assume that the code will be generated as
>> expected.
>>
>> This puts a burden on the test implementors, but could it be argued that
>> this is
>> technically correct? Shouldn't tests be robust? On the other hand, if
>> tests had
>> to specify a target triple, wouldn't this reduce coverage (as they'd be
>> testing
>> a single target as opposed to many)?
>>
>> If this approach was chosen, then a good number of LLVM tests in the
>> open-source
>> tree would need to be adapted, but vendors could be free to implement
>> their own
>> defaults and set the default triple without significant consequences.
>>
>>
>> C - Triple-based option defaults, fixed default triple logic
>> ------------------------------------------------------------
>>
>> This alternative assumes that:
>>
>> - There is some functionality (a new API in llvm::cl?) in the open-source
>> tree
>>   to override the defaults based on the target triple.
>> - Vendors are NOT free to change the logic determining the default triple.
>> - The default triple is inferred by some fixed logic, which is
>> test-friendly.
>>
>> There is code in the Clang driver that parses the program name to identify
>> a
>> prefix that is used to determine the target triple. For example, I seem to
>> understand that "x86_64-scei-ps4-clang" would indicate a Clang which has a
>> PS4
>> target triple by default.
>> Opt, llc, and similar tools do not support anything of the sort, so at the
>> moment the default target triple cannot be selected with the same
>> approach.
>>
>> Anyway, consider the case where option defaults are set based on the
>> target
>> triple, but the default triple can be inferred from the name prefix, just
>> as
>> Clang does; if no such prefix is found, the defaulting falls back to what
>> we do
>> currently. This allows tests with RUN lines running "llc" to just use the
>> triple
>> that we currently use, and therefore all existing open-source tests will
>> continue to work.
>>
>> At the same time, a vendor could release a tool with a name prefix and
>> reap the
>> benefits of having the desired defaults; and to make it convenient for the
>> user,
>> a symlink (or something more complex on Windows) could easily be used.
>>
>> If this approach was chosen, vendor-specific tests which expect the vendor
>> defaults would have to somehow rename the tool on the fly before running
>> it; or
>> maybe they could change the build process to produce both an "llc" and a
>> "<triple>-llc" executables. Also vendors would need to release the renamed
>> tools, but this often happens anyway with cross-compilers. This pushes
>> some
>> burden on the vendor, but it is much less than maintaining a lot of
>> private
>> changes to the open-source code and tests.
>>
>> What does the community think?
>> Discuss. :-)
>>
>> Cheers,
>>     Dario Domizioli
>>     SN Systems - Sony Computer Entertainment Group
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> [hidden email]         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Target-specific defaults for LLVM tools?

Jonathan Roelofs


On 3/17/15 3:19 PM, Steve King wrote:

> Doesn't count for much, but I'm sympathetic to Dario's concern with
> cl::opt and clang defaults.  In one large out-of-tree project,
> colleagues decided to create their own driver to handle the required
> customization of the build process and options.
>
> If clang is the user's one stop shop, here's one such cross compiler
> example I'd like to understand better:  GNU binutils has no clue of my
> target.  Instead of trying to use gas, how should GNU-less targets
> enable clang invoke llvm-mc to assemble?
>
-fintegrated-as / -fno-integrated-as
>


--
Jon Roelofs
[hidden email]
CodeSourcery / Mentor Embedded
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Target-specific defaults for LLVM tools?

Steve King
>> If clang is the user's one stop shop, here's one such cross compiler
>> example I'd like to understand better:  GNU binutils has no clue of my
>> target.  Instead of trying to use gas, how should GNU-less targets
>> enable clang invoke llvm-mc to assemble?
>>
> -fintegrated-as / -fno-integrated-as

I tried, but integrated-as was impractical due to too many possible
machine code matches for a given assembly statement.  So, the compiler
deals in pseudos and emits .s files.  If the integrated assembler
could accept an assembly string instead of an mcinst, I'd be in
business.

Regardless, users could pass .s files on the command line and Clang
would still need to call llvm-mc with the right options.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Target-specific defaults for LLVM tools?

Jonathan Roelofs


On 3/17/15 4:00 PM, Steve King wrote:

>>> If clang is the user's one stop shop, here's one such cross compiler
>>> example I'd like to understand better:  GNU binutils has no clue of my
>>> target.  Instead of trying to use gas, how should GNU-less targets
>>> enable clang invoke llvm-mc to assemble?
>>>
>> -fintegrated-as / -fno-integrated-as
>
> I tried, but integrated-as was impractical due to too many possible
> machine code matches for a given assembly statement.  So, the compiler
> deals in pseudos and emits .s files.  If the integrated assembler
> could accept an assembly string instead of an mcinst, I'd be in
> business.
Which arch is this?
>
> Regardless, users could pass .s files on the command line and Clang
> would still need to call llvm-mc with the right options.
That's sort of what `clang -cc1as` does already when you do: `clang
foo.s -integrated-as`.

--
Jon Roelofs
[hidden email]
CodeSourcery / Mentor Embedded
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Target-specific defaults for LLVM tools?

Reid Kleckner-2
In reply to this post by Steve King
On Tue, Mar 17, 2015 at 3:00 PM, Steve King <[hidden email]> wrote:
>> If clang is the user's one stop shop, here's one such cross compiler
>> example I'd like to understand better:  GNU binutils has no clue of my
>> target.  Instead of trying to use gas, how should GNU-less targets
>> enable clang invoke llvm-mc to assemble?
>>
> -fintegrated-as / -fno-integrated-as

I tried, but integrated-as was impractical due to too many possible
machine code matches for a given assembly statement.  So, the compiler
deals in pseudos and emits .s files.  If the integrated assembler
could accept an assembly string instead of an mcinst, I'd be in
business.

Regardless, users could pass .s files on the command line and Clang
would still need to call llvm-mc with the right options.

Clang already does this without invoking llvm-mc. It invokes 'clang -cc1as' which performs the same function. Try it. :) 

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Target-specific defaults for LLVM tools?

Joerg Sonnenberger
In reply to this post by Steve King
On Tue, Mar 17, 2015 at 03:00:48PM -0700, Steve King wrote:

> >> If clang is the user's one stop shop, here's one such cross compiler
> >> example I'd like to understand better:  GNU binutils has no clue of my
> >> target.  Instead of trying to use gas, how should GNU-less targets
> >> enable clang invoke llvm-mc to assemble?
> >>
> > -fintegrated-as / -fno-integrated-as
>
> I tried, but integrated-as was impractical due to too many possible
> machine code matches for a given assembly statement.  So, the compiler
> deals in pseudos and emits .s files.  If the integrated assembler
> could accept an assembly string instead of an mcinst, I'd be in
> business.
>
> Regardless, users could pass .s files on the command line and Clang
> would still need to call llvm-mc with the right options.

You don't make sense to me. IAS uses the same parser as llvm-mc.

Joerg
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Target-specific defaults for LLVM tools?

Steve King
Clang correctly assembled a .s file when using the -integrated-as
option.  Thanks, that is news to me!  However, without -integrated-as,
clang invoked 'as', which won't work for a GNU-less target.  Accepting
assembler invocation as a good case study for target specific clang
defaults, what is the proper solution?


On Tue, Mar 17, 2015 at 3:21 PM, Joerg Sonnenberger
<[hidden email]> wrote:

> On Tue, Mar 17, 2015 at 03:00:48PM -0700, Steve King wrote:
>> >> If clang is the user's one stop shop, here's one such cross compiler
>> >> example I'd like to understand better:  GNU binutils has no clue of my
>> >> target.  Instead of trying to use gas, how should GNU-less targets
>> >> enable clang invoke llvm-mc to assemble?
>> >>
>> > -fintegrated-as / -fno-integrated-as
>>
>> I tried, but integrated-as was impractical due to too many possible
>> machine code matches for a given assembly statement.  So, the compiler
>> deals in pseudos and emits .s files.  If the integrated assembler
>> could accept an assembly string instead of an mcinst, I'd be in
>> business.
>>
>> Regardless, users could pass .s files on the command line and Clang
>> would still need to call llvm-mc with the right options.
>
> You don't make sense to me. IAS uses the same parser as llvm-mc.
>
> Joerg
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Target-specific defaults for LLVM tools?

Joerg Sonnenberger
On Tue, Mar 17, 2015 at 04:35:07PM -0700, Steve King wrote:
> Clang correctly assembled a .s file when using the -integrated-as
> option.  Thanks, that is news to me!  However, without -integrated-as,
> clang invoked 'as', which won't work for a GNU-less target.  Accepting
> assembler invocation as a good case study for target specific clang
> defaults, what is the proper solution?

Look for hasIntegratedAssembler and IsIntegratedAssemblerDefault.

Joerg
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Target-specific defaults for LLVM tools?

Jonathan Roelofs
In reply to this post by Steve King


On 3/17/15 5:35 PM, Steve King wrote:
> Clang correctly assembled a .s file when using the -integrated-as
> option.  Thanks, that is news to me!  However, without -integrated-as,
> clang invoked 'as', which won't work for a GNU-less target.  Accepting
> assembler invocation as a good case study for target specific clang
> defaults, what is the proper solution?

Again, what is the target architecture? (I understand if it's an
out-of-tree backend that you can't talk about. If so, I'll stop bugging
you about this point.)

For some targets, -integrated-as the default is on, for others it
defaults to off. It generally depends on how good the integrated
assembler is for that target. For example, the default on ARM used to be
-no-integrated-as because IAS just wasn't mature enough at the time.

The "proper solution" here w.r.t. assemblers is to implement full
support for the integrated assembler for the target arch in llvm, and
then flip the default for that target.

--
Jon Roelofs
[hidden email]
CodeSourcery / Mentor Embedded
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Target-specific defaults for LLVM tools?

Dario Domizioli
In reply to this post by David Jones
Thanks for all the replies!

Whoa, it looks like there's pretty much a massive consensus on "use clang and never use opt/llc in that kind of scenario".

I appreciate that opt and llc are mainly debugging/testing tools.
The problem is mainly that these programs "are there" in the open source build of LLVM. Users know that they're getting a product based on open source LLVM, so:
- If opt and llc were not shipped, then it would be reasonable for users to ask: "why can't we have them?"
- If they were shipped, then it would be reasonable for users to ask: "can we have them just work?"

Also, intuitively it feels that llc could be more lightweight / performing compared to clang (which has to spawn a second process), although I admit that I don't have performance numbers for this comparison (yet).

Anyway, now we definitely have an answer for the two questions above. :-)

Cheers,
    Dario Domizioli
    SN Systems - Sony Computer Entertainment Group




On 17 March 2015 at 20:27, David Jones <[hidden email]> wrote:
What is the preferred method for compiler (frontend) developers to optimize and generate target machine code from IR?

At one point I found a tutorial that recommended simply dumping the IR to a file and spawning llc to do the job.

Up until now I have "manually" created a TargetMachine, PassManager, etc. to generate my object code. The initial version of my code was cribbed from llc for LLVM 3.2, and has since been updated for 3.5.1.

However, with every new release of LLVM, the API to the backend optimization and code generation passes changes.  The changes from 3.5.1 to 3.6 are quite significant. If I'm lucky, the impact of a change is that my C++ code refuses to compile, and I have to fix. If I'm unlucky, the impact may be that my code compiles and runs, but LLVM works suboptimally - perhaps some optimizations don't happen. (This can happen if a newer API expects me to do some step which was not required in earlier releases, and there is no assert to catch it.)

As an alternative, I am seriously considering "simply dumping the IR to a file and spawning llc" to perform my backend work. The API to create IR is much more stable than the API to do useful things with it. Furthermore, it's a lot easier to manually debug IR that has been dumped to a file. Finally, I can spawn multiple, independent, concurrent invocations of llc on a multi-core machine. I needn't worry about concurrency, as the standard Linux fork/waitpid type calls will suffice. Given that 90% of my runtime is spent inside LLVM, I get 90% of the benefit of a fully concurrent design with almost zero work.

But now it seems that this usage model is frowned upon.

What is the recommended usage model?


On Tue, Mar 17, 2015 at 2:32 PM, Owen Anderson <[hidden email]> wrote:

On Mar 17, 2015, at 11:13 AM, Dario Domizioli <[hidden email]> wrote:

What does the community think?
Discuss. :-)

Devil’s advocate: opt, llc, lli, etc. are development/debugging tools for LLVM developers, not for end users, and the project optimizes their functionality for that use case.

—Owen

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Target-specific defaults for LLVM tools?

Steve King
In reply to this post by Jonathan Roelofs
Right, sorry to skip over your question.  It is an out-of-tree target
I can't be open about.  I will start a new thread on the integrated-as
problems in my target.


On Tue, Mar 17, 2015 at 4:58 PM, Jonathan Roelofs
<[hidden email]> wrote:

>
>
> On 3/17/15 5:35 PM, Steve King wrote:
>>
>> Clang correctly assembled a .s file when using the -integrated-as
>> option.  Thanks, that is news to me!  However, without -integrated-as,
>> clang invoked 'as', which won't work for a GNU-less target.  Accepting
>> assembler invocation as a good case study for target specific clang
>> defaults, what is the proper solution?
>
>
> Again, what is the target architecture? (I understand if it's an out-of-tree
> backend that you can't talk about. If so, I'll stop bugging you about this
> point.)
>
> For some targets, -integrated-as the default is on, for others it defaults
> to off. It generally depends on how good the integrated assembler is for
> that target. For example, the default on ARM used to be -no-integrated-as
> because IAS just wasn't mature enough at the time.
>
> The "proper solution" here w.r.t. assemblers is to implement full support
> for the integrated assembler for the target arch in llvm, and then flip the
> default for that target.
>
>
> --
> Jon Roelofs
> [hidden email]
> CodeSourcery / Mentor Embedded
>
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Target-specific defaults for LLVM tools?

Dario Domizioli
In reply to this post by Dario Domizioli
Sorry to be a bit controversial, but as a follow-up from this thread, should we then explicitly document that opt, llc and lli are debugging tools in the LLVM documentation?

The LLVM User Guide main page says that "The documentation here is intended for users who have a need to work with the intermediate LLVM representation."
So yes, it is for advanced users, but this wording appears to include users having their own IR generators (they are technically "working with the intermediate representation").

The official man pages for llc, opt and lli certainly make them look like standalone and usable tools:
I can't find anything explicit about them only being debugging/testing tools, nor anything explicitly discouraging their use in production.

Even the "Getting Started with the LLVM System" documentation uses llc in the example!
If llc is just a debugging/testing tool, why does the documentation tell beginners (the obvious target of a "getting started" document) about its existence?!

It could be argued that advanced users "should know better", but the documentation could be clearer too.

Cheers,
    Dario Domizioli
    SN Systems - Sony Computer Entertainment Group




On 18 March 2015 at 00:17, Dario Domizioli <[hidden email]> wrote:
Thanks for all the replies!

Whoa, it looks like there's pretty much a massive consensus on "use clang and never use opt/llc in that kind of scenario".

I appreciate that opt and llc are mainly debugging/testing tools.
The problem is mainly that these programs "are there" in the open source build of LLVM. Users know that they're getting a product based on open source LLVM, so:
- If opt and llc were not shipped, then it would be reasonable for users to ask: "why can't we have them?"
- If they were shipped, then it would be reasonable for users to ask: "can we have them just work?"

Also, intuitively it feels that llc could be more lightweight / performing compared to clang (which has to spawn a second process), although I admit that I don't have performance numbers for this comparison (yet).

Anyway, now we definitely have an answer for the two questions above. :-)

Cheers,
    Dario Domizioli
    SN Systems - Sony Computer Entertainment Group




On 17 March 2015 at 20:27, David Jones <[hidden email]> wrote:
What is the preferred method for compiler (frontend) developers to optimize and generate target machine code from IR?

At one point I found a tutorial that recommended simply dumping the IR to a file and spawning llc to do the job.

Up until now I have "manually" created a TargetMachine, PassManager, etc. to generate my object code. The initial version of my code was cribbed from llc for LLVM 3.2, and has since been updated for 3.5.1.

However, with every new release of LLVM, the API to the backend optimization and code generation passes changes.  The changes from 3.5.1 to 3.6 are quite significant. If I'm lucky, the impact of a change is that my C++ code refuses to compile, and I have to fix. If I'm unlucky, the impact may be that my code compiles and runs, but LLVM works suboptimally - perhaps some optimizations don't happen. (This can happen if a newer API expects me to do some step which was not required in earlier releases, and there is no assert to catch it.)

As an alternative, I am seriously considering "simply dumping the IR to a file and spawning llc" to perform my backend work. The API to create IR is much more stable than the API to do useful things with it. Furthermore, it's a lot easier to manually debug IR that has been dumped to a file. Finally, I can spawn multiple, independent, concurrent invocations of llc on a multi-core machine. I needn't worry about concurrency, as the standard Linux fork/waitpid type calls will suffice. Given that 90% of my runtime is spent inside LLVM, I get 90% of the benefit of a fully concurrent design with almost zero work.

But now it seems that this usage model is frowned upon.

What is the recommended usage model?


On Tue, Mar 17, 2015 at 2:32 PM, Owen Anderson <[hidden email]> wrote:

On Mar 17, 2015, at 11:13 AM, Dario Domizioli <[hidden email]> wrote:

What does the community think?
Discuss. :-)

Devil’s advocate: opt, llc, lli, etc. are development/debugging tools for LLVM developers, not for end users, and the project optimizes their functionality for that use case.

—Owen

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev





_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
12